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: <CAMuHMdUTju=fZ4x5qAwkrRKF8HxvwyKgBD7aD1rPWHGyGFKD-Q@mail.gmail.com>
Date: Thu, 29 Aug 2024 16:34:41 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Rob Herring <robh@...nel.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

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?

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ