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  linux-cve-announce  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]
Message-ID: <20201124112822.2ui57jmoc73top35@skbuf>
Date:   Tue, 24 Nov 2020 11:28:22 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
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" 
        <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

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.

> > 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ