Hi Vladimir,
> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@xxxxxxx>
> Sent: Tuesday, November 24, 2020 7:28 PM
> To: Y.b. Lu <yangbo.lu@xxxxxxx>
> Cc: Michael Walle <michael@xxxxxxxx>; Shawn Guo <shawnguo@xxxxxxxxxx>;
> Leo Li <leoyang.li@xxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>;
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; Adrian
> Hunter <adrian.hunter@xxxxxxxxx>; Ulf Hansson <ulf.hansson@xxxxxxxxxx>;
> linux-mmc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Ashish Kumar
> <ashish.kumar@xxxxxxx>
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>
> On Tue, Nov 24, 2020 at 11:15:19AM +0000, Y.b. Lu wrote:
> > > > Not matter it's SD card or eMMC card, if it's on esdhc0, use
> /dev/mmcblk0.
> > > > Not matter it's SD card or eMMC card, if it's on esdhc1, use
> /dev/mmcblk1.
> > >
> > > With the note here that you can't actually connect an SD card to eSDHC1,
> > > due to the lack of pins for CD/WP.
> >
> > CD/WP is not essential to support SD card. Both SD/eMMC are supported on
> both eSDHC controllers.
>
> Let's keep that discussion separate. While in theory you might be right,
> I think the real-life complications associated with connecting an eMMC
> to eSDHC0 and an SD card to eSDHC1 will make everyone avoid that. So in
> practice they are still single-purpose.
You may refer to Layerscape QDS boards. 5 types SDHC adapters with PCIe connecter supporting SD or eMMC could be used on each esdhc interface.
Another reason using default mmc0 for esdhc0 and mmc1 for esdhc1, is because that's also the order before esdhc driver introducing asynchronous probe.
Distros, bootloaders, and users' cases using fixed index before could avoid issues, and been used as they were.
Thanks.
>
> > > But it is also natural for a customer to define the indices according to
> > > their schematics and what they use. If, say, there is a board that only
> > > uses eMMC, I would expect that for the lay person, no one would even bat
> > > an eye if that was called /dev/mmcblk0. Whereas, if it was called
> > > /dev/mmcblk1 (and there was no /dev/mmcblk0 in the system), maybe
> you'd
> > > have to come up with some explanations which could be avoided.
> >
> > To make a product friendly to users, it makes sense to define different alias
> for controller in board dts.
> > But it's not the reason to remove the default/natural alias in soc dtsi for two
> controllers.
> > What needs to be done after removing them? Add the same to all other
> board files?
>
> Yes.
> In fact, this is also the reason why we prefer to have:
> /soc {
> esdhc: mmc@2140000 {
> status = "disabled";
> };
> };
> in fsl-ls1028a.dtsi
> and
> &esdhc {
> status = "okay";
> };
> in fsl-ls1028a-rdb.dts
> and not the other way around:
>
> /soc {
> esdhc: mmc@2140000 {
> status = "okay";
> };
> };
> in fsl-ls1028a.dtsi
> and
> &esdhc {
> status = "disabled";
> };
> in fsl-ls1028a-rdb.dts
>
> So, in line with that, I think that the entity that enables the node
> should also define the alias.
>
> It's weird to use /delete-property/ if it can be avoided.
