Re: [PATCH v1 1/1] Revert "pinctrl: avoid unsafe code pattern in find_pinctrl()"

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Tue, Oct 17, 2023 at 8:34 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> On Tue, Oct 17, 2023 at 08:18:23PM +0200, Linus Walleij wrote:

> > In the past some file system developers have told us (Ulf will know)
> > that we can't rely on the block device enumeration to identify
> > devices, and requires that we use things such as sysfs or the
> > UUID volume label in ext4 to identify storage.
>
> While I technically might agree with you, this was working for everybody
> since day 1 of support of Intel Merrifield added (circa v4.8), now _user
> space_ is broken.

Actually, I don't agree with that, just relaying it. I would prefer that we
solve exactly the problem that we are facing here: some random unrelated
code or similar affecting enumeration order of mmc devices.

It's not the first time it happens to me, I have several devices that change
this enumeration order depending on whether an SD card is plugged
in or not, and in a *BIG* way: the boot partition on the soldered eMMC
changes enumeration depending on whether an SD card is inserted
or not, and that has never been fixed (because above).

> > That said, device trees are full of stuff like this:
> >
> >         aliases {
> >                 serial0 = &uart_AO;
> >                 mmc0 = &sd_card_slot;
> >                 mmc1 = &sdhc;
> >         };
>
> And Rob, AFAIU, is against aliases.
>
> > Notice how this enumeration gets defined by the aliases.
> >
> > Can you do the same with device properties? (If anyone can
> > answer that question it's Dmitry!)
>
> No, and why should we?

Because device properties are not device tree, they are just some
Linux thing so we can do whatever we want. Just checking if
Dmitry has some idea that would solve this for good, he usually
replies quickly.

Yours,
Linus Walleij