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@xxxxxxxxxxx> > --- > 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
