Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   Peng Fan <peng.fan@nxp.com>
To:     Rob Herring <robh@kernel.org>,
        =?iso-8859-1?Q?Uwe_Kleine-K=F6nig?= 
        <u.kleine-koenig@pengutronix.de>,
        Stefano Stabellini <stefanos@xilinx.com>
CC:     "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
        "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
        "krzk+dt@kernel.org" <krzk+dt@kernel.org>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "wg@grandegger.com" <wg@grandegger.com>,
        "mkl@pengutronix.de" <mkl@pengutronix.de>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        Joakim Zhang <qiangqing.zhang@nxp.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "festevam@gmail.com" <festevam@gmail.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 0/4] dt-bindings: imx: add nvmem property
Thread-Topic: [PATCH 0/4] dt-bindings: imx: add nvmem property
Thread-Index: AQHYPzDdeGvQwiTmbEmT1yMzXeipjazOYVIAgAvbfICAAasQgA==
Date:   Sat, 2 Apr 2022 01:52:28 +0000
Message-ID: <DU0PR04MB94179B979091FC517FB8AEC388E39@DU0PR04MB9417.eurprd04.prod.outlook.com>
References: <20220324042024.26813-1-peng.fan@oss.nxp.com>
 <20220324111104.cd7clpkzzedtcrja@pengutronix.de>
 <YkZEIR1XqJ6sseto@robh.at.kernel.org>
In-Reply-To: <YkZEIR1XqJ6sseto@robh.at.kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?9rSWmk2Bkr5+xvSO4HqCIFGVI0QF30sfj/6uCxv4l+x1xG0rNk/qHUHWAy?=
 =?iso-8859-1?Q?MMWHUFMDaUs9ozCCKtyHxgMP2UZrVY1m52Z6rQavtSzOUJn69ItDY8KZT+?=
 =?iso-8859-1?Q?rIsIi0eDGjgXqATvcvAPG36ZWtsQvdB9wOfiZU11vAmutBtZgslaLaY1Ku?=
 =?iso-8859-1?Q?iGXBk8g878W6I4I1MUqGkmU88+R/JQIifem5Maq/5XHamqCbPIsTY5HCyD?=
 =?iso-8859-1?Q?U8tzdXHW42RCCii5guMzLcd+ieuaMNAM/r6GaWBOH5gysYHklSh2rVLd16?=
 =?iso-8859-1?Q?3nWeI/DeWle95VDkfL5Iea/5h4XhZ7MLtgzhU+VLgi6PtO27EA9KOmwqsG?=
 =?iso-8859-1?Q?l++DhO35KapTSRgeuFGpsXn2i1kQQoafYytEZg7hI4Exg8/jwMmnO6Y8LH?=
 =?iso-8859-1?Q?Yc+tue1+3PtvQ9OsEF8lDGba020pHXj2EtyzOxJ2jRLnQNtwmHTY5wp40n?=
 =?iso-8859-1?Q?1FxeJofdMwwfLBPZCU0igzMYZPgBGTcXnx30FMpcB2NQ/QVrWq5bZIxAKD?=
 =?iso-8859-1?Q?/XNBZrqvNHgw5gddVdGpsETfGDFabg9bdKMBmOPtUMZSirs/hBNo+p7JFB?=
 =?iso-8859-1?Q?wQASVCeEegdJBlBk6I4yYBlgbShDP/qG3xvCmd0iTgzlykuefd2H15ZJO9?=
 =?iso-8859-1?Q?CvvW+8phRsdNIRB5sFUR66kV17TWhpqockE8nhu9x6OkWltOE0FACPtvOZ?=
 =?iso-8859-1?Q?p/hWjTjAmRbQcMwiCPIfTiZ3RUBlkCCGEft/ByAp3fpU2mzFOMQc+ILOCZ?=
 =?iso-8859-1?Q?hqP/LnT2bUGz3wT2dHwzHrJRzYsYhWTl6Q0sEJ5+49pThEMKGorho3fK+M?=
 =?iso-8859-1?Q?JMlm0px43x+n+J0M3EQ1W47EYzIS4sRyFSwbViAMEDGPmyVEyoxJx4Jc+O?=
 =?iso-8859-1?Q?Zj2Vj1/774Kj3rDigbzZe2ypwF6/tVkGX8UrcicBW3G0NzMdHxOWiGJ5Fy?=
 =?iso-8859-1?Q?3rd/AOoh7zE1ldxpYlZxpNP1MAGOKTySa7jFDvzwc5Q/GSAgAZxxGiGfUp?=
 =?iso-8859-1?Q?VdFZQEX0lDn2rHSDwQ5nc2rOfc9gxChT7pwxWjtWo5Hm+1tNpZt/gd5FJB?=
 =?iso-8859-1?Q?W28OGkwcDiYnsAmC9k3Zd3nnFhKcaY4bqfHBX3k30wpJQoPNEo/2SJnucN?=
 =?iso-8859-1?Q?vTQ2KxXFIreiphGyhcGzXy622ozzI3RXjCSL9rsKbuJECwcct/HDkZ/QEt?=
 =?iso-8859-1?Q?ldFYcRr/1uhdetOG9iDsPLxNw1D+TXuNJKt6n+gn2s53mqCrgU6va99Nvk?=
 =?iso-8859-1?Q?B7aY+iWTmIIpCWcFzFZMktbWEMLR4tyr9LXxhnoSmYdA7RnfwIW1K4+ZqC?=
 =?iso-8859-1?Q?4EMHyGrUZ+MehlHKWYBQxt6vJIuPPW4+sPx6eJI8aeYInIYiDESPE0s2RF?=
 =?iso-8859-1?Q?mHvo4uB/2M2eR48MGABcybitMynkyzTjUT5AIDkICSWnUOjuiznDRptPFN?=
 =?iso-8859-1?Q?Ihp2eLw1INqK+SWCBzd8lvrEP+qXt8F2mLWB9zhlvEIOepvCTka5xmSBri?=
 =?iso-8859-1?Q?e+hFsJARsh6KS7SOPv8NWUUq/fcBsaR4P4jUtqL8FxIbjwtbdDMhLhYE01?=
 =?iso-8859-1?Q?3jJ8G3ymUAwCob8nL3BUD1xNQ0sZNz6FP1yjmpT28t8V4nhnVS+0F95jFy?=
 =?iso-8859-1?Q?J/uNC9DGIkBU+nsrUWvtJAd9oRHnld88Qnq75CUuSTmV6fCWGsGgsLBtjR?=
 =?iso-8859-1?Q?9Tp0QSLnZG36OcwfaKTz5xyR6Qc1apjG6+rZk+4jxm/p/RHkIN5d242DbY?=
 =?iso-8859-1?Q?NN9m+bqoQDClgluzNnOCjZekWcSNODIyOXlCMqLiBFXa2d?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR04MB9417.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 078daf56-e203-4519-bbc3-08da144b71d3
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2022 01:52:28.9901
 (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: GbanGGS90/26xm0rOazaqiD3tQ5O/p4Nclc6Y47B+29tPx9Zngq11Q4Z3bgpCKOaOBnwvsKHeEauCzag9HMLtg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB6700
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> Subject: Re: [PATCH 0/4] dt-bindings: imx: add nvmem property
>=20
> On Thu, Mar 24, 2022 at 12:11:04PM +0100, Uwe Kleine-K=F6nig wrote:
> > Hello,
> >
> > On Thu, Mar 24, 2022 at 12:20:20PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > To i.MX SoC, there are many variants, such as i.MX8M Plus which
> > > feature 4 A53, GPU, VPU, SDHC, FLEXCAN, FEC, eQOS and etc.
> > > But i.MX8M Plus has many parts, one part may not have FLEXCAN, the
> > > other part may not have eQOS or GPU.
> > > But we use one device tree to support i.MX8MP including its parts,
> > > then we need update device tree to mark the disabled IP status
> "disabled".
> > >
> > > In NXP U-Boot, we hardcoded node path and runtime update device tree
> > > status in U-Boot according to fuse value. But this method is not
> > > scalable and need encoding all the node paths that needs check.
> > >
> > > By introducing nvmem property for each node that needs runtime
> > > update status property accoridng fuse value, we could use one
> > > Bootloader code piece to support all i.MX SoCs.
> > >
> > > The drawback is we need nvmem property for all the nodes which maybe
> > > fused out.
> >
> > I'd rather not have that in an official binding as the syntax is
> > orthogonal to status =3D "..." but the semantic isn't. Also if we want
> > something like that, I'd rather not want to adapt all bindings, but
> > would like to see this being generic enough to be described in a
> > single catch-all binding.
> >
> > I also wonder if it would be nicer to abstract that as something like:
> >
> > 	/ {
> > 		fuse-info {
> > 			compatible =3D "otp-fuse-info";
> >
> > 			flexcan {
> > 				devices =3D <&flexcan1>, <&flexcan2>;
> > 				nvmem-cells =3D <&flexcan_disabled>;
> > 				nvmem-cell-names =3D "disabled";
> > 			};
> >
> > 			m7 {
> > 				....
> > 			};
> > 		};
> > 	};
> >
> > as then the driver evaluating this wouldn't need to iterate over the
> > whole dtb but just over this node. But I'd still keep this private to
> > the bootloader and not describe it in the generic binding.
>=20
> There's been discussions (under the system DT umbrella mostly) about
> bindings for peripheral enable/disable control/status. Most of the time i=
t is in
> context of device assignment to secure/non-secure world or partitions in =
a
> system (via a partitioning hypervisor).
>=20
> This feels like the same thing and could use the same binding. But someon=
e
> has to take into account all the uses and come up with something. One off
> solutions are a NAK.

Loop Stefano.

Per my understanding, system device tree is not a runtime generated device
tree, in case I am wrong.

To i.MX, one SoC has many different parts, one kind part may not have
VPU, another part may not have GPU, another part may be a full feature
one. We have a device tree for the full feature one, but we not wanna
introduce other static device tree files for non-full feature parts.

So we let bootloader to runtime setting status of a device node according
to fuse info that read out by bootloader at runtime.

I think my case is different with system device tree, and maybe NXP i.MX
specific. So I would introduce a vendor compatible node, following Uwe's
suggestion. We Just need such binding doc and device node in Linux kernel
tree. The code to scan this node is in U-Boot.

/ {
 		fuse-info {
 			compatible =3D "fsl,otp-fuse-info";

 			flexcan {
 				devices =3D <&flexcan1>, <&flexcan2>;
 				nvmem-cells =3D <&flexcan_disabled>;
 				nvmem-cell-names =3D "disabled";
 			};

 			m7 {
 				....
 			};
		};
	};

Thanks,
Peng.

>=20
> Rob