All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: spi-nor: clarify the need for spi-nor compatibles
Date: Fri, 30 Jun 2023 09:36:10 +0100	[thread overview]
Message-ID: <cba4c06c-65ed-141a-80e4-3731c3560ae9@linaro.org> (raw)
In-Reply-To: <20230616140054.2788684-1-miquel.raynal@bootlin.com>

Hi, Miquel,

On 6/16/23 15:00, Miquel Raynal wrote:
> Most SPI NOR devices do not require a specific compatible, their ID can
> in general be discovered with the JEDEC READ ID opcode. In this case,
> only the "jedec,spi-nor" generic compatible is expected. Clarify this
> information in the compatible description to (i) help device-tree
> writers and (ii) prevent further attempts to extend this list with
> useless information.

Sounds good. If you don't mind I'll reword the description from below
when applying.

> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 7149784a36ac..bef071163e38 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -43,8 +43,10 @@ properties:
>            - const: jedec,spi-nor
>        - const: jedec,spi-nor
>      description:
> -      Must also include "jedec,spi-nor" for any SPI NOR flash that can be
> -      identified by the JEDEC READ ID opcode (0x9F).
> +      SPI NOR flashes compatible with the JEDEC standard or which may be

s/JEDEC/JEDEC216, s/may/can

> +      identified with the JEDEC READ ID opcode (0x9F) do not deserve a

"deserve" is a little harsh. How about "must be matched against
the generic ...".

For future me: 0x9f is not a JEDEC216 opcode, it just happened
that the industry agreed on a specific opcode for reading the
ID of the flash. JEDEC216 doesn't care about the flash's ID.
We care because of the fixup hooks.

Cheers,
ta
> +      specific compatible. They should instead only be matched against
> +      the generic "jedec,spi-nor" compatible.
>  
>    reg:
>      minItems: 1

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <michael@walle.cc>,
	linux-mtd@lists.infradead.org
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: spi-nor: clarify the need for spi-nor compatibles
Date: Fri, 30 Jun 2023 09:36:10 +0100	[thread overview]
Message-ID: <cba4c06c-65ed-141a-80e4-3731c3560ae9@linaro.org> (raw)
In-Reply-To: <20230616140054.2788684-1-miquel.raynal@bootlin.com>

Hi, Miquel,

On 6/16/23 15:00, Miquel Raynal wrote:
> Most SPI NOR devices do not require a specific compatible, their ID can
> in general be discovered with the JEDEC READ ID opcode. In this case,
> only the "jedec,spi-nor" generic compatible is expected. Clarify this
> information in the compatible description to (i) help device-tree
> writers and (ii) prevent further attempts to extend this list with
> useless information.

Sounds good. If you don't mind I'll reword the description from below
when applying.

> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 7149784a36ac..bef071163e38 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -43,8 +43,10 @@ properties:
>            - const: jedec,spi-nor
>        - const: jedec,spi-nor
>      description:
> -      Must also include "jedec,spi-nor" for any SPI NOR flash that can be
> -      identified by the JEDEC READ ID opcode (0x9F).
> +      SPI NOR flashes compatible with the JEDEC standard or which may be

s/JEDEC/JEDEC216, s/may/can

> +      identified with the JEDEC READ ID opcode (0x9F) do not deserve a

"deserve" is a little harsh. How about "must be matched against
the generic ...".

For future me: 0x9f is not a JEDEC216 opcode, it just happened
that the industry agreed on a specific opcode for reading the
ID of the flash. JEDEC216 doesn't care about the flash's ID.
We care because of the fixup hooks.

Cheers,
ta
> +      specific compatible. They should instead only be matched against
> +      the generic "jedec,spi-nor" compatible.
>  
>    reg:
>      minItems: 1

  parent reply	other threads:[~2023-06-30  8:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-16 14:00 [PATCH] dt-bindings: mtd: spi-nor: clarify the need for spi-nor compatibles Miquel Raynal
2023-06-16 14:00 ` Miquel Raynal
2023-06-17  7:54 ` Krzysztof Kozlowski
2023-06-17  7:54   ` Krzysztof Kozlowski
2023-06-30  8:36 ` Tudor Ambarus [this message]
2023-06-30  8:36   ` Tudor Ambarus
2023-07-04  8:39   ` Miquel Raynal
2023-07-04  8:39     ` Miquel Raynal
2023-07-13  2:55 ` Tudor Ambarus
2023-07-13  2:55   ` Tudor Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cba4c06c-65ed-141a-80e4-3731c3560ae9@linaro.org \
    --to=tudor.ambarus@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.