[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRMN=d8YX1LG4NSPnNXGnU2u-Ej7wsTom_DpVrD4T_byRE2CQ@mail.gmail.com>
Date: Sun, 11 Jan 2026 18:19:16 -0800
From: Sarav K <sarav.devel@...il.com>
To: Francesco Valla <francesco@...la.it>
Cc: Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>, linux-mmc@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: property: fw_devlink: Add support for "mmc-pwrseq"
On Sat, Jan 10, 2026 at 7:28 AM Francesco Valla <francesco@...la.it> wrote:
>
> Add support for parsing MMC power sequencing (pwrseq) binding so that
> fw_devlink can enforce the dependency.
>
> Signed-off-by: Francesco Valla <francesco@...la.it>
> ---
> Resending this patch as it slipped through the cracks (of my attention,
> at least).
>
> Original submission is at [0]; there it appears as a v2 because it was
> the first time I used b4. It was also part of [1], which wasn't really
> a patchset but a follow-up to the boot time SIG meeting.
>
> I added Ulf and CC'd the mmc list, hoping they can (more
> authoritatively than me) reply to Saravan's question:
>
> """
> I took a quick look at the documentation. It's not clear to me that
> mmc-pwrseq always points to a supplier. Can someone with more
> experience on this confirm that is what it's supposed to point at?
>
> Meaning if A lists B as pwrseq, is it always the case that B needs to
> be powered on? The binding documentation doesn't say anything about B
> needs to be powered on first. It's just saying A and B have an
> ordering requirement.
>
> If the meaning of the binding is _ALWAYS_ B needs to be powered on
> first, then yes, this patch is correct and I can give a reviewed-by.
> """
Ulf, in case you missed it, this email is directed at you or other MMC folks.
Francesco, can you see who added support for that property and direct
your question specifically to them (in case it's not Ulf)?
Is this fixing a specific issue for you that's pressing? If so, we can
land this and then see if anyone complains.
Thanks,
Saravana
>
> [0] https://lore.kernel.org/all/20250930-mmc_pwrseq-v2-1-80a8c6be0fb0@valla.it/
> [1] https://lore.kernel.org/linux-embedded/20251126-beagleplay-probes-v1-0-c833defd4c9b@valla.it/T/
>
> Thank you!
>
> Regards,
> Francesco
> ---
> drivers/of/property.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 4e3524227720a596b0f12976f83357851e9b94f3..05ae33a58b5aec0a8f4d3b7237ce88066d86dc9d 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1410,6 +1410,7 @@ DEFINE_SIMPLE_PROP(post_init_providers, "post-init-providers", NULL)
> DEFINE_SIMPLE_PROP(access_controllers, "access-controllers", "#access-controller-cells")
> DEFINE_SIMPLE_PROP(pses, "pses", "#pse-cells")
> DEFINE_SIMPLE_PROP(power_supplies, "power-supplies", NULL)
> +DEFINE_SIMPLE_PROP(mmc_pwrseq, "mmc-pwrseq", NULL)
> DEFINE_SUFFIX_PROP(regulators, "-supply", NULL)
> DEFINE_SUFFIX_PROP(gpio, "-gpio", "#gpio-cells")
>
> @@ -1557,6 +1558,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
> { .parse_prop = parse_msi_parent, },
> { .parse_prop = parse_pses, },
> { .parse_prop = parse_power_supplies, },
> + { .parse_prop = parse_mmc_pwrseq, },
> { .parse_prop = parse_gpio_compat, },
> { .parse_prop = parse_interrupts, },
> { .parse_prop = parse_interrupt_map, },
>
> ---
> base-commit: b6151c4e60e5f695fac8b5c3e011cfcfd6e27cba
> change-id: 20260110-mmc-pwrseq-e885e677ca2b
>
> Best regards,
> --
> Francesco Valla <francesco@...la.it>
>
Powered by blists - more mailing lists