linux-kernel - Re: [PATCH v5 3/5] dt-bindings: mtd: spi-nor: add OTP parameters

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2fo7pndjqieq6lfydmq2pnwb374oqoqnrcsezycgougmr7mtl5@2wm6fe3inf5u>
Date: Sun, 22 Sep 2024 22:40:26 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Erez Geva <erezgeva@...ime.org>
Cc: linux-mtd@...ts.infradead.org, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, Pratyush Yadav <pratyush@...nel.org>, 
	Michael Walle <mwalle@...nel.org>, linux-kernel@...r.kernel.org, 
	Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger <richard@....at>, 
	Vignesh Raghavendra <vigneshr@...com>, devicetree@...r.kernel.org, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Esben Haabendal <esben@...nix.com>, Erez Geva <ErezGeva2@...il.com>
Subject: Re: [PATCH v5 3/5] dt-bindings: mtd: spi-nor: add OTP parameters

On Fri, Sep 20, 2024 at 08:12:29PM +0200, Erez Geva wrote:
> From: Erez Geva <ErezGeva2@...il.com>
> 
> Some flash devices need OTP parameters in device tree.
> As we can not deduce the parameters based on JEDEC ID or SFDP.
> 
> Signed-off-by: Erez Geva <ErezGeva2@...il.com>
> ---
>  .../bindings/mtd/jedec,spi-nor.yaml           | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 6e3afb42926e..4f7bb3f41cb1 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -90,6 +90,43 @@ properties:
>        the SRWD bit while writing the status register. WP# signal hard strapped to GND
>        can be a valid use case.
>  
> +  otp-n-regions:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Some flash devices need OTP parameters in the device tree.
> +      As we can not deduce the parameters based on JEDEC ID or SFDP.
> +      This parameter indicates the number of OTP regions.

OTP regions where? In DTS? On flash itself?

> +      The value must be larger or equal to 1 and mandatory for OTP.

Don't repeat constraints in free form text. Add proper minimum and
default, although it is confusing - property is not required but it is
mandatory for OTP?



> +
> +  otp-len:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Some flash devices need OTP parameters in the device tree.
> +      As we can not deduce the parameters based on JEDEC ID or SFDP.

Don't repeat the same.

> +      This parameter indicates the size (length) in bytes of an OTP region.

What if each region has different length? Is it possible?

> +      Currently the driver supports symmetric OTP,
> +       which means all regions must use the same size.

Drop unneeded space in front.

> +      The value must be positive and mandatory for OTP.

Same comments as before.

> +
> +  otp-offset:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Some flash devices need OTP parameters in the device tree.
> +      As we can not deduce the parameters based on JEDEC ID or SFDP.
> +      This parameter indicates the offset in bytes of
> +       an OTP region relative to its previous.
> +      User can omit it if the offset equals the length.
> +      Or in case we have a single OTP region.
> +
> +  otp-base:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      Some flash devices need OTP parameters in the device tree.
> +      As we can not deduce the parameters based on JEDEC ID or SFDP.
> +      This parameter indicates the base in bytes of the first OTP region.
> +      User can omit it if the base is zero.

so default: 0?

I am not sure, but all this looks like duplicated description of nvmem
cells or some sort of partitions.

Considering that this is first time the binding mentions OTP, I really
do not get what you are doing it. If the properties are to stay, please
describe better the problem (and hardware!) in commit msg.

Best regards,
Krzysztof