Re: [PATCH v5] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us

[Aaron Tomlin]

On Tue, Jun 02, 2026 at 09:03:28PM -0400, Aaron Tomlin wrote:
> Hi Rafael,
> 
> Thank you for your review and the constructive feedback.
> 
> I certainly appreciate your reasoning concerning the naming convention and
> its current CPU-specific scope.
> 
> However, before I prepare the next iteration, I thought it prudent to
> briefly outline my original architectural reasoning for housing it within
> the generic PM QoS code, simply to ascertain whether you remain of the view
> that cpuidle is the most appropriate home.
> 
> My primary motivation for retaining it within the generic PM QoS framework
> was to maintain strict symmetry with the existing sysfs interface.
> 
> The parameter is designed to align precisely with
> /sys/devices/system/cpu/cpuN/power/pm_qos_resume_latency_us. That sysfs
> attribute is exposed and managed by the generic device PM QoS code, quite
> independently of cpuidle. Furthermore, the boot constraint itself is
> applied via dev_pm_qos_expose_latency_limit(&cpu->dev, ...), which is
> fundamentally a core QoS API.
> 
> Should we move the boot parameter parsing into cpuidle, the consequence is
> that the cpuidle subsystem becomes responsible for parsing a boot string,
> only to immediately pass that data back into the generic PM QoS framework
> during CPU registration. Keeping the implementation within qos.c ensures
> that the parsing logic and the underlying data structures remain cohesively
> in the same subsystem. Crucially, it also preserves the flexibility to
> extend this syntax to non-CPU devices in the future without necessitating
> further refactoring.
> 
> I look forward to hearing your preference.

Hi Rafael,

I am writing to politely enquire whether you have had an opportunity to
consider my reasoning concerning the generic PM QoS framework.

There is absolutely no urgency on my part; however, I am standing by to
rebase and prepare v6 as soon as we reach a consensus on the most
appropriate home for the parsing logic. Please do let me know how you would
prefer to proceed.


Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature