Re: [PATCH v6 03/16] power: sequencing: Add pwrseq_power_is_on()
From: Bartosz Golaszewski
Date: Tue Jul 21 2026 - 05:15:12 EST
On Tue, 21 Jul 2026 08:53:58 +0200, Chen-Yu Tsai <wenst@xxxxxxxxxxxx> said:
> The power sequencing consumer API already does power on state tracking
> internally. Expose the state to consumers through pwrseq_power_is_on()
> so that they don't have to reimplement it locally.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
> Signed-off-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx>
> ---
> Changes since v5:
> - Reverted back to returning -EINVAL if descriptor is NULL
>
> Changes since v4:
> - Make pwrseq_power_is_on() return 1 if descriptor is NULL, i.e. if
> the descriptor is optional, matching the other pwrseq consumer APIs
>
> Changes since v3:
> - Added missing stub function for !POWER_SEQUENCING
>
> Changes since v2:
> - New patch
>
> Needs to go in with "usb: hub: Power on connected M.2 E-key connectors"
> as it is a build time dependency. Bartosz wants the change on an
> immutable branch to pull into the pwrseq tree.
> ---
> drivers/power/sequencing/core.c | 18 ++++++++++++++++++
> include/linux/pwrseq/consumer.h | 6 ++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/power/sequencing/core.c b/drivers/power/sequencing/core.c
> index 02f42da91598..72b96d36920e 100644
> --- a/drivers/power/sequencing/core.c
> +++ b/drivers/power/sequencing/core.c
> @@ -968,6 +968,24 @@ int pwrseq_power_off(struct pwrseq_desc *desc)
> }
> EXPORT_SYMBOL_GPL(pwrseq_power_off);
>
> +/**
> + * pwrseq_power_is_on() - Queries the last requested state of the power sequencer.
> + * @desc: Descriptor referencing the power sequencer.
> + *
> + * This returns the last requested state of the power sequencer.
> + *
> + * Returns:
> + * On success, 1 for on and 0 for off; negative error number on failure.
> + */
> +int pwrseq_power_is_on(struct pwrseq_desc *desc)
> +{
> + if (!desc)
> + return -EINVAL;
> +
> + return desc->powered_on;
> +}
> +EXPORT_SYMBOL_GPL(pwrseq_power_is_on);
> +
Didn't we agree on introducing an enum to make it future-proof for when we
also pull in pwrseq_is_controllable() from Loic?
I think this should work like so:
enum {
PWRSEQ_STATE_UNKNOWN,
PWRSEQ_STATE_ON,
PWRSEQ_STATE_OFF,
};
int pwrseq_get_state(struct pwrseq_desc *desc)
{
/* Only once this is upstream. */
if (!pwrseq_is_controllable(desc))
return PWRSEQ_STATE_UNKNOWN;
return desc->powred_on ? PWRSEQ_STATE_ON : PWRSEQ_STATE_OFF;
}
Bart