drivers/of/property.c | 2 ++ 1 file changed, 2 insertions(+)
Add support for parsing MMC power sequencing (pwrseq) binding so that
fw_devlink can enforce the dependency.
Signed-off-by: Francesco Valla <francesco@valla.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.
"""
[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@valla.it>On Sat, 10 Jan 2026 16:27:59 +0100, Francesco Valla wrote: > Add support for parsing MMC power sequencing (pwrseq) binding so that > fw_devlink can enforce the dependency. > > Signed-off-by: Francesco Valla <francesco@valla.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. > """ > > [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(+) > Applied, thanks!
On Sat, 10 Jan 2026 at 16:28, Francesco Valla <francesco@valla.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@valla.it>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> 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.
> """
>
> [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@valla.it>
>
On Sat, Jan 10, 2026 at 7:28 AM Francesco Valla <francesco@valla.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@valla.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@valla.it>
>
On Mon, 12 Jan 2026 at 03:19, Sarav K <sarav.devel@gmail.com> wrote:
>
> On Sat, Jan 10, 2026 at 7:28 AM Francesco Valla <francesco@valla.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@valla.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?
Yes, the mmc-pwrseq property provides a phandle to the supplier.
> >
> > 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.
I assume with "powered on" you mean "probed". In that case, yes, A
(consumer) can't probe unless B (provider) has probed first.
Up until now, we have relied on deferred probing to manage this.
> >
> > 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 for pinging me about this. Please let me know if there is
anything unclear.
>
> 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@valla.it>
> >
Kind regards
Uffe
© 2016 - 2026 Red Hat, Inc.