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

[Aaron Tomlin]

On Sat, Jun 13, 2026 at 04:33:42PM -0400, Aaron Tomlin wrote:
> 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.


Hi Rafael,

Please excuse the second gentle ping on this thread.

I appreciate how busy things can get, but I wanted to briefly check in to
see whether you have had an opportunity to consider the appropriate home
for the boot parameter parsing logic.

My primary motivation for retaining it within the generic PM QoS framework
was to maintain strict symmetry with the existing sysfs interface.

Original response: https://lore.kernel.org/lkml/3uztb63u72mniljqb2cd4q7cbma2hvns27gn2j2xfm4q4ouuu6@zqyc2wjt55rp/

I am entirely happy to proceed with whichever approach you see fit—please
just let me know your preference and I will get v6 prepared and submitted.


Kind reards,
-- 
Aaron Tomlin