Re: [PATCH v5 03/11] power: sequencing: Add pwrseq_is_controllable() API
Bartosz Golaszewski <[email protected]>
| Newsgroups | org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci,org.kernel.vger.linux-pm |
|---|---|
| Message-ID | <CAMRc=Md6dL8uggf8OJH=tNzCewh7N0AVdVEs5qQreRM3GvcNng@mail.gmail.com> |
On Mon, 20 Jul 2026 10:04:05 +0200, Loic Poulain <[email protected]> said: > On some boards a power sequencing target has no host-controllable enable > for its function, for instance when the enable line is not wired up to a > GPIO and is hardwired to an always-on level. The pcie-m2 "uart" target is > one such example: when the M.2 connector does not route the W_DISABLE2# > signal to a host GPIO, its enable/disable are no-ops and the consumer > cannot gate the Bluetooth function at all or exclusively. > > Add a generic pwrseq_is_controllable() helper. It reports whether the > target's final unit provides a host-controllable dedicated power actuator. > The target can implement a new optional is_controllable() callback, > reporting whether that actuator is effective on this target (for example > depending on GPIO presence). If the target does not provide the callback, > it is assumed to be controllable. > > Note this only describes the target's own enable actuator. It does not > imply that a power-off reaches an electrical OFF state, since a target may > have multiple consumers. It also does not mean that power is uncontrolled > for the target's dependencies: those may still be gated on their own. And > it does not restrict consumers from calling pwrseq_power_off() either, > which remains valid to drop this consumer's vote on the (possibly shared) > resources and dependencies of the target. > > Signed-off-by: Loic Poulain <[email protected]> > --- I don't think it'll make v7.3 but: Acked-by: Bartosz Golaszewski <[email protected]>