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:   Vladimir Oltean <vladimir.oltean@nxp.com>
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" 
        <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: AQHWvovBrojMBFt1EECB86LxwqdSo6nQRb0AgAB8rICABirOgIAABiUAgAAMfQCAAAInAIAAAhyAgAAYuwA=
Date:   Tue, 24 Nov 2020 10:31:29 +0000
Message-ID: <20201124103128.zucizod344dgme4o@skbuf>
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>
In-Reply-To: <AM7PR04MB688518B8AE836C2CC37FED6AF8FB0@AM7PR04MB6885.eurprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <85D12CB16FCD95419E232278741C5556@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1839ef6a-70f2-4ceb-fbdc-08d890641aba
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 10:31:29.1137
 (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: cEjM3f6ReCWQD/A5yBhUIXyCpjHOHgo5zO5XB0I+64dCBpleSez9TyjLAi7EbjDmi/5KcUnMb7lPqT6ooV0uXQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB2800
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Yangbo,

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 specific
> > >> > thing, like re-defining alias, and disabling any IP it not using.
> > >>
> > >> First, why would you put it in the architecture include anyway? That
> > >> is really board-specific. That is like you would say, we enable all
> > >> devices and a board could potentially disable it. TBH it seems that
> > >> 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/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.

> It's not related to board and card type, it's only related to esdhc inter=
face in use.

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.

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.

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:

	sja1105: ethernet-switch@1 {
		ports {
			port@0 {
				/* ETH5 written on chassis */
				label =3D "swp5";
			};

			port@1 {
				/* ETH2 written on chassis */
				label =3D "swp2";
			};

			port@2 {
				/* ETH3 written on chassis */
				label =3D "swp3";
			};

			port@3 {
				/* ETH4 written on chassis */
				label =3D "swp4";
			};
		};
	};

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