From: Michael Walle <michael@walle.cc>
To: Tudor.Ambarus@microchip.com
Cc: Bacem.Daassi@infineon.com, Takahiro.Kuwano@infineon.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
p.yadav@ti.com, richard@nod.at, tkuw584924@gmail.com,
vigneshr@ti.com
Subject: Re: [PATCH v13 1/4] mtd: spi-nor: Retain nor->addr_width at 4BAIT parse
Date: Thu, 21 Apr 2022 15:42:45 +0200 [thread overview]
Message-ID: <5a7ba92487dcb1f776b76dcf069fbdf5@walle.cc> (raw)
In-Reply-To: <af0fd418-7097-c2d4-dbbf-8cde0c62f765@microchip.com>
Am 2022-04-21 15:13, schrieb Tudor.Ambarus@microchip.com:
>> If the parsing wouldn't change any runtime parameters we wouldn't
>> have this problem at all. no?
>
> It doesn't change, _but_ it sets the correct number of address nbytes.
It changes nor->addr_width which might be used for all commands
except the read_sfdp_data(). It changes it before we are entering
the 4 byte mode. Also parse_sfdp changes the opcodes. It seems this
was the reason for the SNOR_F_HAS_4BAIT flag in the first place,
so the core doesn't convert the opcodes again.
>> The parse_sfdp() should only change members of struct
>> spi_nor_flash_parameters, the caller will then decide if they
>> should be used and more imporantly *when* they should be used.
>
> this would mean introducing a nor->params->addr_nbytes, which
> is redundant with SNOR_F_HAS_4BAIT.
So? The SFDP table has both information, I don't see a problem
with that. And I'm not sure they are redunant, I think a flash
can have 4 byte addresses and no 4BAIT table.
And if it would be redundant why do we need that empty
case below..
>> Then you can do the sane thing in spi_nor_set_addr_width():
>> setting the addr_width.
>>
>> Right now it's:
>>
>> +static int spi_nor_set_addr_width(struct spi_nor *nor)
>> +{
>> + if (nor->flags & SNOR_F_HAS_4BAIT)
>> + nor->addr_width = 4;
>> +
>> + if (nor->addr_width) {
>> + /* already configured from SFDP */
>> + }
>> ..
here.
>>
>> Sometimes it will set addr_width, sometimes it will not be set
>> and every once in a while 4byte mode is determined by SFDP but
>> it is not configured (SNOR_F_HAS_4BAIT).
>
> which is good! we prefer using 4b opcodes than entering 4byte address
> mode.
You didn't understand my point. All the assignments of addr_width
are clustered around in the code. Why can't we have them in a common
place. We even have this place already: spi_nor_set_addr_width().
Also you could probably get rid of that "don't change opcodes
if SNOR_F_HAS_4BAIT is set" thingy if the parsing code wouldn't
change the opcodes but returns the parsed ones for the core
to decide what to use. With the benefit of better readability
and lesser bugs.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-04-21 13:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 9:40 [PATCH v13 0/4] mtd: spi-nor: Add support for Infineon s25hl-t/s25hs-t tkuw584924
2022-04-21 9:40 ` [PATCH v13 1/4] mtd: spi-nor: Retain nor->addr_width at 4BAIT parse tkuw584924
2022-04-21 10:38 ` Tudor.Ambarus
2022-04-21 10:48 ` Takahiro Kuwano
2022-04-21 11:29 ` Michael Walle
2022-04-21 12:06 ` Tudor.Ambarus
2022-04-21 13:01 ` Michael Walle
2022-04-21 13:13 ` Tudor.Ambarus
2022-04-21 13:42 ` Michael Walle [this message]
2022-04-21 13:56 ` Tudor.Ambarus
2022-04-21 14:26 ` Takahiro Kuwano
2022-04-27 4:16 ` Takahiro Kuwano
2022-04-27 6:35 ` Tudor.Ambarus
2022-04-21 9:40 ` [PATCH v13 2/4] mtd: spi-nor: spansion: Add support for volatile QE bit tkuw584924
2022-04-21 10:41 ` Tudor.Ambarus
2022-04-21 10:47 ` Takahiro Kuwano
2022-04-21 10:56 ` Tudor.Ambarus
2022-04-21 11:36 ` Tudor.Ambarus
2022-04-21 11:48 ` Tudor.Ambarus
2022-04-22 9:04 ` Takahiro Kuwano
2022-04-21 9:40 ` [PATCH v13 3/4] mtd: spi-nor: spansion: Add local function to discover page size tkuw584924
2022-04-21 10:43 ` Tudor.Ambarus
2022-04-22 9:14 ` Takahiro Kuwano
2022-04-21 9:40 ` [PATCH v13 4/4] mtd: spi-nor: spansion: Add s25hl-t/s25hs-t IDs and fixups tkuw584924
2022-04-21 10:45 ` Tudor.Ambarus
2022-04-21 10:53 ` Takahiro Kuwano
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=5a7ba92487dcb1f776b76dcf069fbdf5@walle.cc \
--to=michael@walle.cc \
--cc=Bacem.Daassi@infineon.com \
--cc=Takahiro.Kuwano@infineon.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=tkuw584924@gmail.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