On Fri, Jul 31, 2026 at 03:42:18PM +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. pwrseq_vote_on/off() also have been rejected as unusual in > the tree. > > Change the name of the two functions to pwrseq_enable/disable() which > better reflects their purpose and semantics and also mirrors other > enable-counted resources like regulators and clocks. No functional change > intended. > > If at any point users need to know *when* the exact power event happens, > we can provide that information in the form of a notifier. > > Acked-by: Jeff Johnson <[email protected]> > Acked-by: Bjorn Helgaas <[email protected]> > Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Manivannan Sadhasivam <[email protected]> - Mani -- மணிவண்ணன் சதாசிவம்
