linux-kernel - [PATCH] of: property: fw_devlink: Add support for "mmc-pwrseq"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260110-mmc-pwrseq-v1-1-73de9d6456f4@valla.it>
Date: Sat, 10 Jan 2026 16:27:59 +0100
From: Francesco Valla <francesco@...la.it>
To: Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...nel.org>, 
 Ulf Hansson <ulf.hansson@...aro.org>
Cc: linux-mmc@...r.kernel.org, devicetree@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Francesco Valla <francesco@...la.it>
Subject: [PATCH] of: property: fw_devlink: Add support for "mmc-pwrseq"

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.
"""

[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>