Re: [PATCH RFC] power: sequencing: rename pwrseq_power_on/off() to pwrseq_vote_on/off()
Manivannan Sadhasivam <[email protected]> Thu, 30 Jul 2026 18:52:25 +0200
| Newsgroups | org.infradead.lists.ath10k,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-pm,org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <aht3dm6gijcltk2kblilwd33ihrapdwbco2fd5wxrqmsuppqde@3s3242otfa5h> |
On Mon, Jul 27, 2026 at 11:14:35AM -0500, Bjorn Helgaas wrote: > On Mon, Jul 27, 2026 at 11:57:38AM +0200, Bartosz Golaszewski wrote: > > The way power sequencing works means that a call to pwrseq_power_on() > > does not necessarily result in the pwrseq target being powered-on at > > that time: it may have already been powered on before. Similarly: a call > > to pwrseq_power_off() does not have to result in an actual powering off > > of resources: there may still be other users that requested a power-on > > before. > > > > We will also introduce the concept of "non-controllable" pwrseq targets > > soon which further increases the disconnect between the naming > > convention and the actual semantics. > > > > What consumers of pwrseq descriptors actually do is: they *vote* for a > > powering on of a given target or retract that vote. These operations > > could be called get/put in line with runtime PM but this could become > > confusing since we already provide pwrseq_get/put() for a different > > purpose. > > I see the possible confusion with get/put interfaces, but "vote" > doesn't seem exactly right because it really is refcounting, not a > majority vote thing. > > Maybe enable/disable is a possibility, since regulator_enable() and > regulator_disable() have the same kind of refcount behavior? > +1 - Mani -- மணிவண்ணன் சதாசிவம்