lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 25 Nov 2020 02:59:41 +0000
From:   "Y.b. Lu" <yangbo.lu@....com>
To:     Vladimir Oltean <vladimir.oltean@....com>
CC:     Michael Walle <michael@...le.cc>, Shawn Guo <shawnguo@...nel.org>,
        Leo Li <leoyang.li@....com>, Rob Herring <robh+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ashish Kumar <ashish.kumar@....com>
Subject: RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
 controllers use fixed indices

Hi Vladimir,

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@....com>
> Sent: Tuesday, November 24, 2020 7:28 PM
> To: Y.b. Lu <yangbo.lu@....com>
> Cc: Michael Walle <michael@...le.cc>; Shawn Guo <shawnguo@...nel.org>;
> Leo Li <leoyang.li@....com>; Rob Herring <robh+dt@...nel.org>;
> linux-arm-kernel@...ts.infradead.org; devicetree@...r.kernel.org; Adrian
> Hunter <adrian.hunter@...el.com>; Ulf Hansson <ulf.hansson@...aro.org>;
> linux-mmc@...r.kernel.org; linux-kernel@...r.kernel.org; Ashish Kumar
> <ashish.kumar@....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@...0000 {
> 		status = "disabled";
> 	};
> };
> in fsl-ls1028a.dtsi
> and
> &esdhc {
> 	status = "okay";
> };
> in fsl-ls1028a-rdb.dts
> and not the other way around:
> 
> /soc {
> 	esdhc: mmc@...0000 {
> 		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.

Powered by blists - more mailing lists