From: Michael Walle <michael@walle.cc>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Tudor Ambarus <tudor.ambarus@linaro.org>,
Rob Herring <robh@kernel.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Pratyush Yadav <pratyush@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts
Date: Fri, 22 Sep 2023 09:59:08 +0200 [thread overview]
Message-ID: <f4751046b26a86b18aa7e446a4da81e8@walle.cc> (raw)
In-Reply-To: <CAMuHMdUKxJDPs3Ow8E-g2bLr7c7jREf5gSqWZ+o5aWbGj6uO=w@mail.gmail.com>
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
next prev parent reply other threads:[~2023-09-22 7:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 13:37 [PATCH] dt-bindings: mtd: jedec,spi-nor: Document support for more MT25QU parts Geert Uytterhoeven
2022-12-02 13:50 ` Michael Walle
2022-12-02 13:56 ` Geert Uytterhoeven
2022-12-05 16:33 ` Rob Herring
2022-12-06 8:32 ` Geert Uytterhoeven
2023-09-21 14:45 ` Tudor Ambarus
2023-09-21 15:10 ` Geert Uytterhoeven
2023-09-21 16:01 ` Michael Walle
2023-09-21 17:01 ` Geert Uytterhoeven
2023-09-22 7:10 ` Geert Uytterhoeven
2023-09-22 7:59 ` Michael Walle [this message]
2022-12-05 16:25 ` Rob Herring
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=f4751046b26a86b18aa7e446a4da81e8@walle.cc \
--to=michael@walle.cc \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=tudor.ambarus@linaro.org \
--cc=tudor.ambarus@microchip.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).