From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Krzysztof Kozlowski <krzk@kernel.org>, Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree-spec@vger.kernel.org, quentin.schulz@cherry.de,
Marc Kleine-Budde <mkl@pengutronix.de>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
Krzysztof Kozlowski <krzk+dt@kernel.org>
Subject: Re: SoC-specific device tree aliases?
Date: Wed, 3 Dec 2025 12:34:45 +0100 [thread overview]
Message-ID: <ddc6fa7b-7840-4340-be41-8f28aad1c80e@pengutronix.de> (raw)
In-Reply-To: <6638e499-2320-41c9-b720-faf4f976e476@kernel.org>
Hello Krzysztof,
On 12/3/25 11:25 AM, Krzysztof Kozlowski wrote:
> On 03/12/2025 11:16, Ahmad Fatoum wrote:
>>> Just because ufs/mmc/spi can be used that way, does not mean we should
>>> accept any possible alias into soc.dtsi.
>>
>> I can't see how this could work. A number of boards renumber MMC devices
>> in a different manner than the SoC reference manual:
>>
>> - Changing the alias numbering is an ABI break, because Linux derives
>> its /dev/mmcblkX numbering from it
>
> First, why the alias would change? Isn't the board following the SoC
> numbering in 99.9% cases?
For 32-bit i.MX, the figure is more like 80% with 20% of the boards
going out of their way to override the numbering in the SoC dtsi.
I can only assume the figure may be higher for other platforms, where
there is no numbering in the DTSI. See below[1] for calculation.
> Second, I don't think it is an ABI. We had it ~5 or ~8 years ago where
> the mmcblkX was changing based on probe ordering. Many people setups got
> broken, many people complained and the consensus reply was: please start
> finally using UUID/PARTUIID/LABEL for rootfs.
On the other hand, I have seen people flashing the same image to both an
eMMC and a SD-Card and wondering why the bootloader picks a different
rootfs than the kernel.
> Eventually we got back to
> mmcblkX stability but rule is there - if your cmdline has /dev/mmcblkX,
> then it is your problem.
Device tree aliases are the only way to identify the same MMC device
in bootloader and kernel over different boots and for my part, I can
only encourage their use.
[1]: I checked out Linux v6.18, used imx_v6_v7_defconfig and built the
dtb target.
arch/arm/boot/dts/nxp/imx/.*.dtb.dts.tmp in the build directory are the
preprocessed device tree source files.
I deleted arch/arm/boot/dts/nxp/imx/.imx7ulp*.dtb.dts.tmp, because
it's the only SoC apparently that numbers MMC peripherals stating with 0.
Now let's find all instances of mmcX = somethingY, where X is not Y - 1:
perl -ne '/mmc(\d+)\s*=\s*&\w+?(\d+)/ && $1 != $2 - 1 and \
print($ARGV, $_) && close ARGV' \
arch/arm/boot/dts/nxp/imx/.*.dtb.dts.tmp
This returns 76 matches out of a total 381, so that's 19.95% of all i.MX
device trees that went out of their way to override the numbering in the
SoC dtsi.
Cheers,
Ahmad
>
>
>
>
> Best regards,
> Krzysztof
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-12-03 11:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 8:28 SoC-specific device tree aliases? Ahmad Fatoum
2025-11-13 18:04 ` Rob Herring
2025-11-13 19:17 ` Doug Anderson
2025-11-13 20:24 ` Heiko Stübner
2025-11-14 9:13 ` Ahmad Fatoum
2025-11-17 7:38 ` Krzysztof Kozlowski
2025-11-17 8:26 ` Sascha Hauer
2025-11-17 9:52 ` Krzysztof Kozlowski
2025-11-17 10:34 ` Sascha Hauer
2025-11-17 10:41 ` Krzysztof Kozlowski
2025-11-17 12:56 ` Marc Kleine-Budde
2025-11-17 13:18 ` Krzysztof Kozlowski
2025-11-17 14:52 ` Sascha Hauer
2025-11-17 14:57 ` Krzysztof Kozlowski
2025-11-17 15:23 ` Sascha Hauer
2025-11-17 15:44 ` Krzysztof Kozlowski
2025-11-17 16:06 ` Rob Herring
2025-11-17 16:29 ` Krzysztof Kozlowski
2025-12-03 10:16 ` Ahmad Fatoum
2025-12-03 10:25 ` Krzysztof Kozlowski
2025-12-03 10:36 ` Matthias Schiffer
2025-12-03 11:08 ` Krzysztof Kozlowski
2025-12-03 11:37 ` Ahmad Fatoum
2025-12-03 17:51 ` Rob Herring
2025-12-04 7:59 ` Sascha Hauer
2025-12-04 13:44 ` Rob Herring
2025-12-03 11:20 ` Marc Kleine-Budde
2025-12-03 11:24 ` Krzysztof Kozlowski
2025-12-03 11:34 ` Ahmad Fatoum [this message]
2025-12-04 18:51 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddc6fa7b-7840-4340-be41-8f28aad1c80e@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=conor+dt@kernel.org \
--cc=devicetree-spec@vger.kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=mkl@pengutronix.de \
--cc=quentin.schulz@cherry.de \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).