Re: Please review the patch "mmc: core: try to use an id from the devicetree " again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 19 Dec 2019 at 11:57, Johnson CH Chen (陳昭勳)
<JohnsonCH.Chen@xxxxxxxx> wrote:
>
> Dear Ulf,
>
> We have a requirement to set a specific mmc's disk slot for a root path when booting. I think a specific "slot" is different from a specific "device". For example, When a platform has four mmc/sd slots, and we have ten mmc/sd cards. We need to test some cards for booting in one slot, and other slots can be filled with one card each for another use. Actually the order of these four slots is not constant because it depends on the order of registering mmc/sd drivers, and different platforms may have different situations. Slot id can be related with block id, so it can be related with mmc id for current linux kernel, too. We need to set a specific slot id to satisfy our requirement.
>
> I find the following patch: https://lkml.org/lkml/2019/6/20/638
> This is Lubomir provides has a function we need. Actually I have a patch with similar function without mmc alias and just set "mmc-id" in device tree, but I think Lubomir's is better than myself.
>
> Someone think why not use "LABEL" or "UUID" for initramfs, or use "PARTLABEL" or "PARTUUID" for u-boot? I think they assign a specific numbers/characters for mmc/sd cards, not for mmc/sd slots. Besides, if I set the same "LABEL" or "PARTLABEL" in some mmc/sd card, I think kernel will be confused how to find a desired mmc/sd card.
>
> So kindly review the patch "mmc: core: try to use an id from the devicetree " if you are free, thanks!

There have been several attempts to fix this and me personally don't
have a problem with using aliases/labels in DT. I said that before as
well.

However, what is missing today, is that someone collects the proper
arguments for *why* this is needed (and especially why UUID/LABEL
doesn't work). I think all that information is available in the
discussion here: https://lore.kernel.org/patchwork/cover/674381/

When I see a new patch posted, that contains these arguments in the
commit message of the patch, I am ready to review it again.

Kind regards
Uffe




[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux