netdev - RE: [PATCH 0/4] dt-bindings: imx: add nvmem property

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: <DU0PR04MB94179B979091FC517FB8AEC388E39@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date:   Sat, 2 Apr 2022 01:52:28 +0000
From:   Peng Fan <peng.fan@....com>
To:     Rob Herring <robh@...nel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        Stefano Stabellini <stefanos@...inx.com>
CC:     "Peng Fan (OSS)" <peng.fan@....nxp.com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "wg@...ndegger.com" <wg@...ndegger.com>,
        "mkl@...gutronix.de" <mkl@...gutronix.de>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        Joakim Zhang <qiangqing.zhang@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH 0/4] dt-bindings: imx: add nvmem property

> Subject: Re: [PATCH 0/4] dt-bindings: imx: add nvmem property
> 
> On Thu, Mar 24, 2022 at 12:11:04PM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Thu, Mar 24, 2022 at 12:20:20PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@....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 = "..." 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 = "otp-fuse-info";
> >
> > 			flexcan {
> > 				devices = <&flexcan1>, <&flexcan2>;
> > 				nvmem-cells = <&flexcan_disabled>;
> > 				nvmem-cell-names = "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.
> 
> There's been discussions (under the system DT umbrella mostly) about
> bindings for peripheral enable/disable control/status. Most of the time it is in
> context of device assignment to secure/non-secure world or partitions in a
> system (via a partitioning hypervisor).
> 
> This feels like the same thing and could use the same binding. But someone
> 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 = "fsl,otp-fuse-info";

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

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

Thanks,
Peng.

> 
> Rob