On Fri, 31 Jul 2026 10:43:19 +0200, Loic Poulain <[email protected]> said: > On Fri, Jul 31, 2026 at 10:29 AM Bartosz Golaszewski > <[email protected]> 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]> >> --- >> I've floated the idea to rename the two pwrseq functions from "power >> on/off" to "vote on/off". I've sent a patch but the overwhelming >> consensus seem to be that enable/disable naming is preferred. >> >> I'm doing it in a single commit that should go through the pwrseq tree >> with Acks from subsystem maintainers. >> >> [1] >> https://lore.kernel.org/all/CAMRc=Mefxn81d0VUwmQgwFtffkL1=er_1vqzcbc1sa-qph4...@mail.gmail.com/ >> --- >> Changes in v2: >> - Change the naming convention to enable/disable >> - Link to v1: >> https://patch.msgid.link/[email protected] >> --- >> Documentation/driver-api/pwrseq.rst | 4 ++-- >> drivers/bluetooth/hci_qca.c | 4 ++-- >> drivers/gpu/drm/imagination/pvr_power.c | 4 ++-- >> drivers/net/wireless/ath/ath10k/snoc.c | 6 +++--- >> drivers/pci/pwrctrl/generic.c | 4 ++-- >> drivers/pci/pwrctrl/pci-pwrctrl-pwrseq.c | 4 ++-- >> drivers/power/sequencing/core.c | 16 ++++++++-------- >> include/linux/pwrseq/consumer.h | 8 ++++---- >> 8 files changed, 25 insertions(+), 25 deletions(-) >> >> diff --git a/Documentation/driver-api/pwrseq.rst >> b/Documentation/driver-api/pwrseq.rst >> index >> ad18b2326b689a41471216f3889480b11768ca82..0c315ab1138b02540fae60b39928c580027c0f7c >> 100644 >> --- a/Documentation/driver-api/pwrseq.rst >> +++ b/Documentation/driver-api/pwrseq.rst >> @@ -50,9 +50,9 @@ Consumer interface >> The consumer API is aimed to be as simple as possible. The driver >> interested in >> getting a descriptor from the power sequencer should call pwrseq_get() and >> specify the name of the target it wants to reach in the sequence after >> calling >> -pwrseq_power_up(). The descriptor can be released by calling pwrseq_put() >> and >> +pwrseq_enable(). The descriptor can be released by calling pwrseq_put() and >> the consumer can request the powering down of its target with >> -pwrseq_power_off(). Note that there is no guarantee that pwrseq_power_off() >> +pwrseq_disble(). Note that there is no guarantee that pwrseq_disble() >> will have any effect as there may be multiple users of the underlying >> resources >> who may keep them active. >> >> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c >> index >> 345f602e9ce233a0934a73a85d1e7c17c4f3210d..e713fc06b73402ae3d57794ed0870df8394a796a >> 100644 >> --- a/drivers/bluetooth/hci_qca.c >> +++ b/drivers/bluetooth/hci_qca.c >> @@ -2259,7 +2259,7 @@ static void qca_power_off(struct hci_uart *hu) >> } >> >> if (power && power->pwrseq) { >> - pwrseq_power_off(power->pwrseq); >> + pwrseq_disble(power->pwrseq); > > Nit: s/pwrseq_disble/pwrseq_disable ? >
Ah dang it, how did I miss it, I test-built it. :/ Thanks for catching it. Bart
