[PATCH] arm64: dts: ls1028a: make the eMMC and SD card controllers use fixed indices

[Y.b. Lu]

Hi Vladimir,

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean at nxp.com>
> Sent: Tuesday, November 24, 2020 7:28 PM
> To: Y.b. Lu <yangbo.lu at nxp.com>
> Cc: Michael Walle <michael at walle.cc>; Shawn Guo <shawnguo at kernel.org>;
> Leo Li <leoyang.li at nxp.com>; Rob Herring <robh+dt at kernel.org>;
> linux-arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; Adrian
> Hunter <adrian.hunter at intel.com>; Ulf Hansson <ulf.hansson at linaro.org>;
> linux-mmc at vger.kernel.org; linux-kernel at vger.kernel.org; Ashish Kumar
> <ashish.kumar at nxp.com>
> 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 at 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 at 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.