linux-kernel - Re: [PATCH v3 1/7] dt-bindings: fuse: Move renesas,rcar-{efuse,otp} to nvmem

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] [day] [month] [year] [list]

Message-ID: <20240830154719.GA45646-robh@kernel.org>
Date: Fri, 30 Aug 2024 10:47:19 -0500
From: Rob Herring <robh@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
	Arnd Bergmann <arnd@...db.de>, devicetree@...r.kernel.org,
	linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/7] dt-bindings: fuse: Move renesas,rcar-{efuse,otp}
 to nvmem

On Thu, Aug 29, 2024 at 04:34:41PM +0200, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Thu, Aug 29, 2024 at 3:58 PM Rob Herring <robh@...nel.org> wrote:
> > On Thu, Aug 29, 2024 at 11:10:41AM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 29, 2024 at 10:55 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > > On 28/08/2024 22:10, Geert Uytterhoeven wrote:
> > > > > On Mon, Aug 19, 2024 at 1:11 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > > > >> On Wed, Jul 31, 2024 at 09:37:36AM +0200, Geert Uytterhoeven wrote:
> > > > >>> On Tue, Jul 30, 2024 at 6:24 PM Rob Herring <robh@...nel.org> wrote:
> > > > >>>> On Fri, Jul 26, 2024 at 03:38:06PM +0200, Geert Uytterhoeven wrote:
> > > > >>>>> The R-Car E-FUSE blocks can be modelled better using the nvmem
> > > > >>>>> framework.
> > > > >>>>>
> > > > >>>>> Replace the R-Car V3U example by an R-Car S4-8 ES1.2 example, to show
> > > > >>>>> the definition of nvmem cells.  While at it, drop unneeded labels from
> > > > >>>>> the examples, and fix indentation.
> > > > >>>>>
> > > > >>>>> Add an entry to the MAINTAINERS file.
> > > > >>>>>
> > > > >>>>> Reported-by: Arnd Bergmann <arnd@...db.de>
> > > > >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > > > >>>>> ---
> > > > >>>>> v3:
> > > > >>>>>   - New.
> > > > >>>>>
> > > > >>>>> I would expect that the calib@144 node needs:
> > > > >>>>>
> > > > >>>>>     #nvmem-cell-cells = <0>;
> > > >
> > > > So this is for mac-base...
> > >
> > > No, mac-base is not involved.
> >
> > It is because that's the only case that allows #nvmem-cell-cells in
> > fixed-cell.yaml. While fixed-cell.yaml allows additional properties,
> > where it is referenced in fixed-layout.yaml does not.
> 
> So all of this is normal, and you should just never use #nvmem-cell-cells,
> except in a node describing the location of the MAC address?

I was just explaining the source. If you have another use, then adjust 
the schema.

> When no #nvmem-cell-cells property is present,
> of_parse_phandle_with_optional_args() (as used in
> of_nvmem_cell_get()) returns zero anyway

Yeah, I don't see much value in disallowing #nvmem-cell-cells.

Rob