From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
knaerzche@gmail.com, Nicolas.Ferre@microchip.com,
linux-mtd@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
zhengxunli@mxic.com.tw, p.yadav@ti.com, mail@david-bauer.net,
code@reto-schneider.ch
Subject: Re: [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes
Date: Thu, 03 Mar 2022 17:39:02 +0100 [thread overview]
Message-ID: <27c305208aba4b028a535ae68c9b3a77@walle.cc> (raw)
In-Reply-To: <239af41b-6f60-f7c6-3523-40f9e333c9db@microchip.com>
Am 2022-03-03 17:03, schrieb Tudor.Ambarus@microchip.com:
..
>>>>> So when one
>>>>> declares a flash like:
>>>>> + { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64)
>>>>> + /* ID collision with mx25l3233f. */
>>>>> + PARSE_SFDP
>>>>> + NO_SFDP_FLAGS(SECT_4K)
>>>>
>>>> But what about
>>>> + { "differentflash", INFO(0xc22016, 0, 64 * 1024, 64)
>>>> + /* ID collision with mx25l3233f. */
>>>> + PARSE_SFDP
>>>>
>>>> Thats also valid, no? Why is having 4k sectors special? FWIW, the
>>>
>>> no, because just the first entry with the 0xc22016 ID will be hit,
>>> the
>>> second one will be ignored. We use a single flash entry for all the
>>> flashes that collide.
>>
>> Not in addition but instead of yours, of course.
>>
>>> PARSE_SFDP together with any of the:
>>> #define SECT_4K BIT(1)
>>> #define SECT_4K_PMC BIT(2)
>>> #define SPI_NOR_DUAL_READ BIT(3)
>>> #define SPI_NOR_QUAD_READ BIT(4)
>>> #define SPI_NOR_OCTAL_READ BIT(5)
>>> #define SPI_NOR_OCTAL_DTR_READ BIT(6)
>>> #define SPI_NOR_OCTAL_DTR_PP BIT(7)
>>>
>>> suggests that we'd like to differentiate between a flash that
>>> supports
>>> SFDP and can discover its params via SFDP (no_sfdp_flags will be
>>> ignored),
>>> and a flash that doesn't support SFDP and it's forced to initialize
>>> the
>>> params via the no_sfdp_flags.
>>
>> I get that, but what if I have a flash, which doesn't have 4k
>> sectors but ordinary 64k sectors (to stick to your example). In
>> general, what if I have a flash where none of the above flags
>> are set. You only call that function if there are any no_sfdp flags
>> set, but they are all optional, no? Who is setting the erase opcode
>> for flashes with that ID but without SFDP, then?
>
> this use case is not handled in this proposal, indeed. I'm not sure
> if there are such flashes though. Can't think of an example. We search
> for a flash that operates only in 1-1-1 and can't do 4k erase.
> Is that a NOR? But if you feel we should care about this case too,
> I'll address it, probably I will be forced to introduce a new flag or
> a bool, meh.
1-1-1 with 64k sectors would be the very basic spi nor flash no?
In any case, no I don't care that much about this, it was just not
that easy to understand why you did it this way. So we should
really add a comment that we assume here that at least one
nosfdp flag is set.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-03-03 16:40 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-28 13:44 [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Tudor Ambarus
2022-02-28 13:45 ` [PATCH v4 1/6] mtd: spi-nor: core: Report correct name in case of " Tudor Ambarus
2022-03-01 21:38 ` Michael Walle
2022-04-05 19:41 ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes Tudor Ambarus
2022-03-01 21:52 ` Michael Walle
2022-03-03 14:41 ` Tudor.Ambarus
2022-03-03 14:51 ` Michael Walle
2022-03-03 15:25 ` Tudor.Ambarus
2022-03-03 15:42 ` Michael Walle
2022-03-03 16:03 ` Tudor.Ambarus
2022-03-03 16:39 ` Michael Walle [this message]
2022-02-28 13:45 ` [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Tudor Ambarus
2022-03-01 21:57 ` Michael Walle
2022-03-03 15:28 ` Tudor.Ambarus
2022-03-03 15:33 ` Michael Walle
[not found] ` <CAEyMn7aN+wJnYkTJU_nWA9bPzF1sezA9_=E5YG5rnPBLMAmabA@mail.gmail.com>
2022-03-03 16:45 ` Michael Walle
2022-03-04 0:36 ` Tudor.Ambarus
2022-03-04 14:36 ` Michael Walle
2022-04-05 19:50 ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 4/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L12805D and MX25L12835F Tudor Ambarus
2022-03-01 7:55 ` Heiko Thiery
2022-03-01 8:52 ` Tudor.Ambarus
2022-03-01 9:31 ` Heiko Thiery
2022-02-28 13:45 ` [PATCH v4 5/6] mtd: spi-nor: Introduce Manufacturer ID collisions driver Tudor Ambarus
2022-03-01 22:19 ` Michael Walle
2022-03-03 16:12 ` Tudor.Ambarus
2022-03-03 21:38 ` Michael Walle
2022-03-04 7:07 ` Tudor.Ambarus
2022-03-04 14:10 ` Michael Walle
2022-03-04 21:20 ` George Brooke
2022-03-07 7:07 ` Tudor.Ambarus
2022-02-28 13:45 ` [PATCH v4 6/6] mtd: spi-nor: manuf-id-collisions: Add support for xt25f128b Tudor Ambarus
2022-03-01 22:23 ` Michael Walle
2022-03-03 21:04 ` Chris Morgan
2022-03-03 23:50 ` Tudor.Ambarus
2022-03-04 2:23 ` Chris Morgan
2022-02-28 13:55 ` [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Michael Walle
2022-02-28 15:39 ` [PATCH] mtd: spi-nor: Move XMC to manufacturer ID collisions driver Tudor Ambarus
2022-03-01 6:47 ` [PATCH v2] " 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=27c305208aba4b028a535ae68c9b3a77@walle.cc \
--to=michael@walle.cc \
--cc=Nicolas.Ferre@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=code@reto-schneider.ch \
--cc=esben@geanix.com \
--cc=heiko.thiery@gmail.com \
--cc=jaimeliao@mxic.com.tw \
--cc=knaerzche@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=macromorgan@hotmail.com \
--cc=mail@david-bauer.net \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=sr@denx.de \
--cc=vigneshr@ti.com \
--cc=zhengxunli@mxic.com.tw \
/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