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: <z56fiu2jpokp57sjvnrdcbfy7brpq2ag4yxpektqlhtidecx4n@vc7dsurhxorb>
Date: Wed, 14 Feb 2024 10:31:56 +0100
From: Markus Schneider-Pargmann <msp@...libre.com>
To: Rob Herring <robh@...nel.org>
Cc: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>, 
	Tero Kristo <kristo@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, 
	Conor Dooley <conor+dt@...nel.org>, Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, 
	Santosh Shilimkar <ssantosh@...nel.org>, Andrew Davis <afd@...com>, linux-arm-kernel@...ts.infradead.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] dt-bindings: hwinfo: ti,k3-socinfo: Add nvmem-cells

Hi Rob,

On Tue, Feb 06, 2024 at 06:43:05PM +0000, Rob Herring wrote:
> On Tue, Feb 06, 2024 at 03:37:09PM +0100, Markus Schneider-Pargmann wrote:
> > The information k3-socinfo requires is stored in an efuse area. This
> > area is required by other devices/drivers as well, so using nvmem-cells
> > can be a cleaner way to describe which information are used.
> > 
> > If nvmem-cells are supplied, the address range is not required.
> > Cells chipvariant, chippartno and chipmanufacturer are introduced to
> > cover all required information.
> > 
> > Signed-off-by: Markus Schneider-Pargmann <msp@...libre.com>
> > Reviewed-by: Andrew Davis <afd@...com>
> > ---
> >  .../bindings/hwinfo/ti,k3-socinfo.yaml        | 23 ++++++++++++++++++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> > index dada28b47ea0..f085b7275b7d 100644
> > --- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> > +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
> > @@ -26,9 +26,24 @@ properties:
> >    reg:
> >      maxItems: 1
> >  
> > +  nvmem-cells:
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  nvmem-cell-names:
> > +    items:
> > +      - const: chipvariant
> > +      - const: chippartno
> > +      - const: chipmanufacturer
> > +
> >  required:
> >    - compatible
> > -  - reg
> > +
> > +oneOf:
> > +  - required:
> > +      - reg
> > +  - required:
> > +      - nvmem-cells
> > +      - nvmem-cell-names
> >  
> >  additionalProperties: false
> >  
> > @@ -38,3 +53,9 @@ examples:
> >          compatible = "ti,am654-chipid";
> >          reg = <0x43000014 0x4>;
> >      };
> > +  - |
> > +    chipid: chipid@14 {
> > +        compatible = "ti,am654-chipid";
> 
> This isn't compatible if you have a completely different way to access 
> it. 

Thanks, it is not entirely clear to me how I could go forward with this?
Are you suggesting to use a different compatible? Or is it something
else I could do to proceed with this conversion?

Thank you!

Best,
Markus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ