Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Y.b. Lu" <yangbo.lu@nxp.com>
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
CC:     Michael Walle <michael@walle.cc>, Shawn Guo <shawnguo@kernel.org>,
        Leo Li <leoyang.li@nxp.com>, Rob Herring <robh+dt@kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Ashish Kumar <ashish.kumar@nxp.com>
Subject: RE: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
 controllers use fixed indices
Thread-Topic: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
 controllers use fixed indices
Thread-Index: AQHWvovBvcqJCTixR025fdiTeTkR06nQRXqQgAB88ACABimgIIAAB1IAgAAEgOCAAAokAIAAAQaQgAAZ0oCAAARV8A==
Date:   Tue, 24 Nov 2020 11:15:19 +0000
Message-ID: <AM7PR04MB688567CA698191E2DB73DEF5F8FB0@AM7PR04MB6885.eurprd04.prod.outlook.com>
References: <20201119155025.965941-1-vladimir.oltean@nxp.com>
 <AM7PR04MB688536E10A0B35D75A9F8F34F8FF0@AM7PR04MB6885.eurprd04.prod.outlook.com>
 <20201120093015.duel3yx63cbya77w@skbuf>
 <VI1PR04MB6896C22F6B304F365C3BA626F8FB0@VI1PR04MB6896.eurprd04.prod.outlook.com>
 <71a86b0fbc95892f8fd240e0919e7e23@walle.cc>
 <AM7PR04MB6885CA8A965A49C456454254F8FB0@AM7PR04MB6885.eurprd04.prod.outlook.com>
 <3293d698bf26ecf08f22e7e2ffe55e74@walle.cc>
 <AM7PR04MB688518B8AE836C2CC37FED6AF8FB0@AM7PR04MB6885.eurprd04.prod.outlook.com>
 <20201124103128.zucizod344dgme4o@skbuf>
In-Reply-To: <20201124103128.zucizod344dgme4o@skbuf>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c72867a9-3ef7-444e-993f-08d8906a3a46
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 11:15:19.0368
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ueAEvh+gG7fsN/KXSvrsQShy2hjRS2lqZ44YfvI+UDamQo916A8qcRIzkRkODlD86LbZ+cZHjwt+xYBDd0t/pA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR04MB7608
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Vladimir,

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Sent: Tuesday, November 24, 2020 6:31 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: Michael Walle <michael@walle.cc>; Shawn Guo <shawnguo@kernel.org>;
> Leo Li <leoyang.li@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Adrian
> Hunter <adrian.hunter@intel.com>; Ulf Hansson <ulf.hansson@linaro.org>;
> linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Ashish Kumar
> <ashish.kumar@nxp.com>
> Subject: Re: [PATCH] arm64: dts: ls1028a: make the eMMC and SD card
> controllers use fixed indices
>=20
> Hi Yangbo,
>=20
> On Tue, Nov 24, 2020 at 09:02:57AM +0000, Y.b. Lu wrote:
> > > Am 2020-11-24 09:47, schrieb Y.b. Lu:
> > > > Hi Michael,
> > > >> > I don't think it's a problem in board dts to define board specif=
ic
> > > >> > thing, like re-defining alias, and disabling any IP it not using=
.
> > > >>
> > > >> First, why would you put it in the architecture include anyway? Th=
at
> > > >> is really board-specific. That is like you would say, we enable al=
l
> > > >> devices and a board could potentially disable it. TBH it seems tha=
t
> > > >> this will fit your reference boards and you don't care about the
> > > >> other ones which uses that include.
> > > >
> > > > In soc dtsi, this is giving default alias for two esdhc controllers=
.
> > > > This is not board specific.
> > > > That's natural esdhc0 is mmc0 and esdhc1 is mmc1.
> > >
> > > How could this be not board specific if there are at least three
> > > different use cases the board can choose from - and needs three
> > > different configurations:
> > >
> > > (1) eMMC at /dev/mmcblk0, SD card at /dev/mmcblk1
> > > (2) SD card at /dev/mmcblk0, eMMC at /dev/mmcblk1
> > > (3) no eMMC at all, SD card at /dev/mmcblk0
> >
> > Not matter it's SD card or eMMC card, if it's on esdhc0, use /dev/mmcbl=
k0.
> > Not matter it's SD card or eMMC card, if it's on esdhc1, use /dev/mmcbl=
k1.
>=20
> 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 bo=
th eSDHC controllers.

>=20
> > It's not related to board and card type, it's only related to esdhc int=
erface in
> use.
>=20
> I understand the hardware-centric view that you are coming from. It may
> be natural for you that eSDHC0 is for the SD card and eSDHC1 is for eMMC,
> because these are the designations in the SoC.

Right, from hardware-centric view, it's natural esdhc0 interface is mmc0, a=
nd esdhc1 is mmc1.
That's what I explained for why I added the alias in common soc dtsi.


>=20
> 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 ali=
as 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?

This is just my opinion. I don't decide on this:)

>=20
> I am only a passerby when it comes to the MMC subsystem. But in
> networking/DSA, it is frequent that the board designer comes up with
> their own numbering scheme, which has nothing to do with the numbering
> of the chip. Consider this extreme case from
> arch/arm/boot/dts/ls1021a-tsn.dts:
>=20
> 	sja1105: ethernet-switch@1 {
> 		ports {
> 			port@0 {
> 				/* ETH5 written on chassis */
> 				label =3D "swp5";
> 			};
>=20
> 			port@1 {
> 				/* ETH2 written on chassis */
> 				label =3D "swp2";
> 			};
>=20
> 			port@2 {
> 				/* ETH3 written on chassis */
> 				label =3D "swp3";
> 			};
>=20
> 			port@3 {
> 				/* ETH4 written on chassis */
> 				label =3D "swp4";
> 			};
> 		};
> 	};
>=20
> You just have to go along with how the hardware is being used in the
> product. I could have insisted that hardware switch port 0 is named as
> swp0, but that would have not helped anybody.