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

[Michael Walle]

Hi Yangbo, Hi Shawn,

Am 2020-11-25 03:59, schrieb Y.b. Lu:
> > -----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.

Just for completeness, on the LS1028A there is definetly one for eMMC
and one for SD card. One supports voltage switching and one has a 8bit
data bus. But as Vladimir already said, this doesn't matter for this
discussion.

> Another reason using default mmc0 for esdhc0 and mmc1 for esdhc1, is
> because that's also the order before esdhc driver introducing
> asynchronous probe.

No if there was
  &esdhc { status = "disabled" };
this would change the block device from /dev/mmcblk0 to /dev/mmcblk1
for the remaining &esdhc1.

We are going cirlces here. I guess Shawn (as the soc maintainer) has to
step in and decide if a common soc include should contain aliases for
nodes which are disabled. That is what it boils down to.

All other arguments against having aliases in the common include can be
found in this thread.

> Distros, bootloaders, and users' cases using fixed index before could
> avoid issues, and been used as they were.

Nobody argue against having these alias. We are arguing against having
them in the common soc include.

-michael