[PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
FLASHes.

Merge the new entries with the existing entry for MT25QU02G.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
mt25qu512a is already in active use, causing "make dtbs_check" errors.
mt25qu256a is supported by the Linux spi-nor driver, but there are no
upstream users yet.
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 6cc491083650a0f9..92f65f682059a6ea 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -19,6 +19,7 @@ properties:
       - items:
           - pattern: "^((((micron|spansion|st),)?\
               (m25p(40|80|16|32|64|128)|\
+              mt25qu(02g|256a|512a)|\
               n25q(32b|064|128a11|128a13|256a|512a|164k)))|\
               atmel,at25df(321a|641|081a)|\
               everspin,mr25h(10|40|128|256)|\
@@ -34,7 +35,6 @@ properties:
       - items:
           - enum:
               - issi,is25lp016d
-              - micron,mt25qu02g
               - mxicy,mx25r1635f
               - mxicy,mx25u6435f
               - mxicy,mx25v8035f
-- 
2.25.1

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Michael Walle]

Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
> Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> FLASHes.
> 
> Merge the new entries with the existing entry for MT25QU02G.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> mt25qu512a is already in active use, causing "make dtbs_check" errors.
> mt25qu256a is supported by the Linux spi-nor driver, but there are no
> upstream users yet.

Is it encouraged to use the specific compatible with SPI-NOR flashes?
As far as I know it isn't. The spi-nor subsys tries hard to identify
any flashes at runtime and any additional information in the device tree
is used as a last resort (just for flashes which doesn't support the
read jedec id command yet). And usually boards have different sources
for flash chips, so hardcoding a particular part in the device tree
doesn't make sense.

just my 2 cents,
-michael

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

Hi Michael,

On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
> Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
> > Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> > FLASHes.
> >
> > Merge the new entries with the existing entry for MT25QU02G.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > mt25qu512a is already in active use, causing "make dtbs_check" errors.
> > mt25qu256a is supported by the Linux spi-nor driver, but there are no
> > upstream users yet.
>
> Is it encouraged to use the specific compatible with SPI-NOR flashes?
> As far as I know it isn't. The spi-nor subsys tries hard to identify
> any flashes at runtime and any additional information in the device tree
> is used as a last resort (just for flashes which doesn't support the
> read jedec id command yet). And usually boards have different sources
> for flash chips, so hardcoding a particular part in the device tree
> doesn't make sense.

Thanks, I am aware there have been pushbacks when trying to
document more compatible values.

IMHO either all or none of them should be documented.
If device-specific compatible values are discouraged, the bindings
should be updated to reflect that, and document a single compatible
value ("jedec,spi-nor") only.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Rob Herring]

On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote:
> Hi Michael,
> 
> On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
> > Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
> > > Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> > > FLASHes.
> > >
> > > Merge the new entries with the existing entry for MT25QU02G.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > > mt25qu512a is already in active use, causing "make dtbs_check" errors.
> > > mt25qu256a is supported by the Linux spi-nor driver, but there are no
> > > upstream users yet.
> >
> > Is it encouraged to use the specific compatible with SPI-NOR flashes?
> > As far as I know it isn't. The spi-nor subsys tries hard to identify
> > any flashes at runtime and any additional information in the device tree
> > is used as a last resort (just for flashes which doesn't support the
> > read jedec id command yet). And usually boards have different sources
> > for flash chips, so hardcoding a particular part in the device tree
> > doesn't make sense.
> 
> Thanks, I am aware there have been pushbacks when trying to
> document more compatible values.
> 
> IMHO either all or none of them should be documented.
> If device-specific compatible values are discouraged, the bindings
> should be updated to reflect that, and document a single compatible
> value ("jedec,spi-nor") only.

That's already allowed, so there's your answer.

The caveat is don't be adding them later to your DT when you find an 
issue and new quirk properties will probably be rejected.

Rob

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

Hi Rob,

On Mon, Dec 5, 2022 at 5:33 PM Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote:
> > On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
> > > Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
> > > > Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> > > > FLASHes.
> > > >
> > > > Merge the new entries with the existing entry for MT25QU02G.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > > mt25qu512a is already in active use, causing "make dtbs_check" errors.
> > > > mt25qu256a is supported by the Linux spi-nor driver, but there are no
> > > > upstream users yet.
> > >
> > > Is it encouraged to use the specific compatible with SPI-NOR flashes?
> > > As far as I know it isn't. The spi-nor subsys tries hard to identify
> > > any flashes at runtime and any additional information in the device tree
> > > is used as a last resort (just for flashes which doesn't support the
> > > read jedec id command yet). And usually boards have different sources
> > > for flash chips, so hardcoding a particular part in the device tree
> > > doesn't make sense.
> >
> > Thanks, I am aware there have been pushbacks when trying to
> > document more compatible values.
> >
> > IMHO either all or none of them should be documented.
> > If device-specific compatible values are discouraged, the bindings
> > should be updated to reflect that, and document a single compatible
> > value ("jedec,spi-nor") only.
>
> That's already allowed, so there's your answer.

It's indeed allowed, but the alternative is documented, too (for some
values).

> The caveat is don't be adding them later to your DT when you find an
> issue and new quirk properties will probably be rejected.

Adding them later to your DT when you find an issue makes no sense,
as that breaks compatibility with older DTBs.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Tudor Ambarus]

Hi, Geert,

Sorry for the delay, I just noticed this while cleaning the patchwork log.

On 12/6/22 08:32, Geert Uytterhoeven wrote:
> Hi Rob,
> 
> On Mon, Dec 5, 2022 at 5:33 PM Rob Herring <robh@kernel.org> wrote:
>> On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote:
>>> On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
>>>> Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
>>>>> Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
>>>>> FLASHes.
>>>>>
>>>>> Merge the new entries with the existing entry for MT25QU02G.
>>>>>
>>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>> ---
>>>>> mt25qu512a is already in active use, causing "make dtbs_check" errors.
>>>>> mt25qu256a is supported by the Linux spi-nor driver, but there are no
>>>>> upstream users yet.
>>>>
>>>> Is it encouraged to use the specific compatible with SPI-NOR flashes?
>>>> As far as I know it isn't. The spi-nor subsys tries hard to identify
>>>> any flashes at runtime and any additional information in the device tree
>>>> is used as a last resort (just for flashes which doesn't support the
>>>> read jedec id command yet). And usually boards have different sources
>>>> for flash chips, so hardcoding a particular part in the device tree
>>>> doesn't make sense.
>>>
>>> Thanks, I am aware there have been pushbacks when trying to
>>> document more compatible values.
>>>
>>> IMHO either all or none of them should be documented.
>>> If device-specific compatible values are discouraged, the bindings
>>> should be updated to reflect that, and document a single compatible
>>> value ("jedec,spi-nor") only.
>>
>> That's already allowed, so there's your answer.
> 
> It's indeed allowed, but the alternative is documented, too (for some
> values).
> 
>> The caveat is don't be adding them later to your DT when you find an
>> issue and new quirk properties will probably be rejected.
> 
> Adding them later to your DT when you find an issue makes no sense,
> as that breaks compatibility with older DTBs.
> 

We won't break compatibility with older DTBs if we use a list of
compatibles. First the vendor specific one which will use some quirks,
and if that's not available, have as second the generic jedec,spi-nor to
fallback to.

Cheers,
ta

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

Hi Tudor,

On Thu, Sep 21, 2023 at 4:45 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
> Sorry for the delay, I just noticed this while cleaning the patchwork log.
> On 12/6/22 08:32, Geert Uytterhoeven wrote:
> > On Mon, Dec 5, 2022 at 5:33 PM Rob Herring <robh@kernel.org> wrote:
> >> On Fri, Dec 02, 2022 at 02:56:01PM +0100, Geert Uytterhoeven wrote:
> >>> On Fri, Dec 2, 2022 at 2:50 PM Michael Walle <michael@walle.cc> wrote:
> >>>> Am 2022-12-02 14:37, schrieb Geert Uytterhoeven:
> >>>>> Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> >>>>> FLASHes.
> >>>>>
> >>>>> Merge the new entries with the existing entry for MT25QU02G.
> >>>>>
> >>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >>>>> ---
> >>>>> mt25qu512a is already in active use, causing "make dtbs_check" errors.
> >>>>> mt25qu256a is supported by the Linux spi-nor driver, but there are no
> >>>>> upstream users yet.
> >>>>
> >>>> Is it encouraged to use the specific compatible with SPI-NOR flashes?
> >>>> As far as I know it isn't. The spi-nor subsys tries hard to identify
> >>>> any flashes at runtime and any additional information in the device tree
> >>>> is used as a last resort (just for flashes which doesn't support the
> >>>> read jedec id command yet). And usually boards have different sources
> >>>> for flash chips, so hardcoding a particular part in the device tree
> >>>> doesn't make sense.
> >>>
> >>> Thanks, I am aware there have been pushbacks when trying to
> >>> document more compatible values.
> >>>
> >>> IMHO either all or none of them should be documented.
> >>> If device-specific compatible values are discouraged, the bindings
> >>> should be updated to reflect that, and document a single compatible
> >>> value ("jedec,spi-nor") only.
> >>
> >> That's already allowed, so there's your answer.
> >
> > It's indeed allowed, but the alternative is documented, too (for some
> > values).
> >
> >> The caveat is don't be adding them later to your DT when you find an
> >> issue and new quirk properties will probably be rejected.
> >
> > Adding them later to your DT when you find an issue makes no sense,
> > as that breaks compatibility with older DTBs.
>
> We won't break compatibility with older DTBs if we use a list of
> compatibles. First the vendor specific one which will use some quirks,
> and if that's not available, have as second the generic jedec,spi-nor to
> fallback to.

Sure, you should use a list.

But the current recommended practice is to not have a list,
but just "jedec,spi-nor" (using a list with a new FLASH part name
causes checkpatch and dtbs_check warnings). Hence if you follow that
recommendation, you will run into compatibility issues with older DTBs
when you discover the quirk later, and decide to add it to the list.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Michael Walle]

Hi Geert,

>> We won't break compatibility with older DTBs if we use a list of
>> compatibles. First the vendor specific one which will use some quirks,
>> and if that's not available, have as second the generic jedec,spi-nor 
>> to
>> fallback to.
> 
> Sure, you should use a list.
> 
> But the current recommended practice is to not have a list,
> but just "jedec,spi-nor" (using a list with a new FLASH part name
> causes checkpatch and dtbs_check warnings). Hence if you follow that
> recommendation, you will run into compatibility issues with older DTBs
> when you discover the quirk later, and decide to add it to the list.

The SPI NOR flashes should be auto discoverable. Why do you need a
compatible string? Quirks can be added to the flash_info database.

Also note, that one reason *not* to add a particular flash compatible
is that they are usually interchangeable and OEMs do so. So a where
today a board might have a macronix flash, tomorrow that board might
have a gigadevice one for example.

-michael

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

Hi Michael,

On Thu, Sep 21, 2023 at 6:01 PM Michael Walle <michael@walle.cc> wrote:
> >> We won't break compatibility with older DTBs if we use a list of
> >> compatibles. First the vendor specific one which will use some quirks,
> >> and if that's not available, have as second the generic jedec,spi-nor
> >> to
> >> fallback to.
> >
> > Sure, you should use a list.
> >
> > But the current recommended practice is to not have a list,
> > but just "jedec,spi-nor" (using a list with a new FLASH part name
> > causes checkpatch and dtbs_check warnings). Hence if you follow that
> > recommendation, you will run into compatibility issues with older DTBs
> > when you discover the quirk later, and decide to add it to the list.
>
> The SPI NOR flashes should be auto discoverable. Why do you need a
> compatible string? Quirks can be added to the flash_info database.

This assumes you don't need the quirk before you can identify the part.
I'm not sure that is always the case.

There's a similar issue with Ethernet PHYs on the MDIO bus, which is
why they are gaining proper compatible values in many board DTS files.

> Also note, that one reason *not* to add a particular flash compatible
> is that they are usually interchangeable and OEMs do so. So a where
> today a board might have a macronix flash, tomorrow that board might
> have a gigadevice one for example.

Yeah, that's indeed happening, and it's already an issue.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Geert Uytterhoeven]

On Thu, Sep 21, 2023 at 7:01 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Sep 21, 2023 at 6:01 PM Michael Walle <michael@walle.cc> wrote:
> > >> We won't break compatibility with older DTBs if we use a list of
> > >> compatibles. First the vendor specific one which will use some quirks,
> > >> and if that's not available, have as second the generic jedec,spi-nor
> > >> to
> > >> fallback to.
> > >
> > > Sure, you should use a list.
> > >
> > > But the current recommended practice is to not have a list,
> > > but just "jedec,spi-nor" (using a list with a new FLASH part name
> > > causes checkpatch and dtbs_check warnings). Hence if you follow that
> > > recommendation, you will run into compatibility issues with older DTBs
> > > when you discover the quirk later, and decide to add it to the list.
> >
> > The SPI NOR flashes should be auto discoverable. Why do you need a
> > compatible string? Quirks can be added to the flash_info database.
>
> This assumes you don't need the quirk before you can identify the part.
> I'm not sure that is always the case.

Reminder where this is apparently not the case:
https://lore.kernel.org/r/OS0PR01MB5922A4F16DE8923373AA5DD886F7A@OS0PR01MB5922.jpnprd01.prod.outlook.com/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Michael Walle]

Am 2023-09-22 09:10, schrieb Geert Uytterhoeven:
> On Thu, Sep 21, 2023 at 7:01 PM Geert Uytterhoeven 
> <geert@linux-m68k.org> wrote:
>> On Thu, Sep 21, 2023 at 6:01 PM Michael Walle <michael@walle.cc> 
>> wrote:
>> > >> We won't break compatibility with older DTBs if we use a list of
>> > >> compatibles. First the vendor specific one which will use some quirks,
>> > >> and if that's not available, have as second the generic jedec,spi-nor
>> > >> to
>> > >> fallback to.
>> > >
>> > > Sure, you should use a list.
>> > >
>> > > But the current recommended practice is to not have a list,
>> > > but just "jedec,spi-nor" (using a list with a new FLASH part name
>> > > causes checkpatch and dtbs_check warnings). Hence if you follow that
>> > > recommendation, you will run into compatibility issues with older DTBs
>> > > when you discover the quirk later, and decide to add it to the list.
>> >
>> > The SPI NOR flashes should be auto discoverable. Why do you need a
>> > compatible string? Quirks can be added to the flash_info database.
>> 
>> This assumes you don't need the quirk before you can identify the 
>> part.
>> I'm not sure that is always the case.

Yes, but that seems a reasonable assumption.

> Reminder where this is apparently not the case:
> https://lore.kernel.org/r/OS0PR01MB5922A4F16DE8923373AA5DD886F7A@OS0PR01MB5922.jpnprd01.prod.outlook.com/

I think that one is still under discussion and there is something
strange going on there. In any case, the "read id" operation is done
with just single bit I/O, IOW, RDID should work. Unless there is a
hardware bug and the SPI controller (!) will hold the flash in reset
by pulling down IO3. I'd argue, that simply looking at the flash
compatible is the wrong approach here.

-michael

Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts

[Rob Herring]

On Fri, Dec 02, 2022 at 02:37:58PM +0100, Geert Uytterhoeven wrote:
> Document support for the Micron MT25QU256A and MT25QU512A Serial NOR
> FLASHes.
> 
> Merge the new entries with the existing entry for MT25QU02G.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> mt25qu512a is already in active use, causing "make dtbs_check" errors.
> mt25qu256a is supported by the Linux spi-nor driver, but there are no
> upstream users yet.
> ---
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 6cc491083650a0f9..92f65f682059a6ea 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -19,6 +19,7 @@ properties:
>        - items:
>            - pattern: "^((((micron|spansion|st),)?\
>                (m25p(40|80|16|32|64|128)|\
> +              mt25qu(02g|256a|512a)|\

Let's not add new cases where the vendor is optional.

>                n25q(32b|064|128a11|128a13|256a|512a|164k)))|\
>                atmel,at25df(321a|641|081a)|\
>                everspin,mr25h(10|40|128|256)|\
> @@ -34,7 +35,6 @@ properties:
>        - items:
>            - enum:
>                - issi,is25lp016d
> -              - micron,mt25qu02g
>                - mxicy,mx25r1635f
>                - mxicy,mx25u6435f
>                - mxicy,mx25v8035f
> -- 
> 2.25.1
> 
>