devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 11:16:44 +0100	[thread overview]
Message-ID: <bcb359cf-0e8a-46ec-9f69-51c4c9e8874e@pengutronix.de> (raw)
In-Reply-To: <07ee3540-d0c1-436e-9e1d-db1952f609a6@kernel.org>

Hello Krzysztof,

On 11/17/25 5:29 PM, Krzysztof Kozlowski wrote:
> On 17/11/2025 17:06, Rob Herring wrote:
>>> So you want it to be an ABI for barebox, sure, just make it a binding.
>>
>> What do you have in mind? Other than standard names for the aliases,
>> what can we check here? That a specific alias points to a specific
>> path? That would be a bit too much IMO. That would be equivalent to
>> specifying possible values in 'reg' for all devices.
> 
> Binding with pattern or list of needed alias names, referenced by given
> soc-platform top-level schema.
> 
> One of the points is to make it explicit and obvious (e.g. to Arnd or to
> me if I forget, because I follow the same logic of aliases per board)
> that these aliases are used outside of kernel.
> 
> 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

- Leaving them as-is means they are not usable for boot source determination

That's why I am suggesting a separate node that reflects only the SoC
reference manual's numbering. I don't see how a schema for the existing
/aliases would remove the need for this.

Thanks,
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 |


  reply	other threads:[~2025-12-03 10:16 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 [this message]
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
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=bcb359cf-0e8a-46ec-9f69-51c4c9e8874e@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).