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
