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 -- மணிவண்ணன் சதாசிவம்
