From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Michael Walle <michael@walle.cc>,
Linus Walleij <linus.walleij@linaro.org>
Cc: Pratyush Yadav <pratyush@kernel.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] mtd: spi-nor: Correct flags for Winbond w25q128
Date: Tue, 18 Jul 2023 06:23:55 +0300 [thread overview]
Message-ID: <d99d87e7-47ba-d6fe-735f-16de2a2ec280@linaro.org> (raw)
In-Reply-To: <0525440a652854a2a575256cd07d3559@walle.cc>
On 13.07.2023 10:01, Michael Walle wrote:
> Hi,
>
> Am 2023-07-13 05:32, schrieb Tudor Ambarus:
>> Hi, Linus,
>>
>> On 13.07.2023 00:59, Linus Walleij wrote:
>>> The Winbond "w25q128" (actual vendor name W25Q128JV)
>>> has exactly the same flags as the sibling device
>>> "w25q128jv". The devices both require unlocking to
>>> enable write access.
>>>
>>> The actual product naming between devices vs the
>>> Linux strings in winbond.c:
>>>
>>> 0xef4018: "w25q128" W25Q128JV-IM/JM
>>> 0xef7018: "w25q128jv" W25Q128JV-IN/IQ/JQ
>>>
>>> The latter device, "w25q128jv" supports features
>>> named DTQ and QPI, otherwise it is the same.
>>>
>>> Not having the right flags has the annoying side
>>> effect that write access does not work.
>>
>> I guess you refer to the locking flags. Probably your flash has the non
>> volatile block protection (BP) bits from the Status Register set, which
>> means the entire flash is write protected. The factory default for these
>> bits is 0/disabled on this flash so someone must have played with them.
>> The reason why one may want write protection set is to avoid inadvertent
>> writes during power-up.
>> One can control whether to disable the software write protection at boot
>> time with the MTD_SPI_NOR_SWP_ configs.
>>>
>>> After this patch I can write to the flash on the
>>> Inteno XG6846 router.
>>>
>>> The flash memory also supports dual and quad SPI
>>> modes. This does not currently manifest, but by
>>
>> The fasted mode is chosen after SFDP parsing, so you should use quad
>> reads if your controller also supports 4 I/O lines.
>>> turning on SFDP parsing, the right SPI modes are
>>> emitted in
>>> /sys/kernel/debug/spi-nor/spi1.0/capabilities
>>> for this chip, so we also turn on this.
>>>
>>> Cc: stable@vger.kernel.org
>>> Suggested-by: Michael Walle <michael@walle.cc>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> Changes in v2:
>>> - Only add the write access flags.
>>> - Use SFDP parsing to properly detect the various
>>> available SPI modes.
>>> - Link to v1:
>>> https://lore.kernel.org/r/20230712-spi-nor-winbond-w25q128-v1-1-f78f3bb42a1c@linaro.org
>>> ---
>>> drivers/mtd/spi-nor/winbond.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/spi-nor/winbond.c
>>> b/drivers/mtd/spi-nor/winbond.c
>>> index 834d6ba5ce70..6c82e525c801 100644
>>> --- a/drivers/mtd/spi-nor/winbond.c
>>> +++ b/drivers/mtd/spi-nor/winbond.c
>>> @@ -121,7 +121,8 @@ static const struct flash_info
>>> winbond_nor_parts[] = {
>>> { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16)
>>> NO_SFDP_FLAGS(SECT_4K) },
>>> { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256)
>>
>> while here try, using INFO with INFO(0xef4018, 0, 0, 0), those
>> parameters shall be discovered at run-time, so we prepare to get rid of
>> explicitly setting them sooner or later.
>
> This is an entry matching various flash families from Winbond, see my
> reply in v1. I'm not sure we should remove these as we could break the
> older ones, which might or might not have SFDP tables. We don't know.
I'd take the risk and break the older ones if there are some that don't
define SFDP indeed, just to handle the conflict properly. We can't
encourage code based on assumptions otherwise we'll get back to the
knotted spi-nor code that we tried to untie in the last years.
>
>>
>>> - NO_SFDP_FLAGS(SECT_4K) },
>
> Thus, I'd also keep this one.
>
Keeping this one does not have the effect that you want as SECT_4K is
used in spi_nor_no_sfdp_init_params() which is not called when
PARSE_SFDP is set, which makes perfectly sense. Let's drop this and if
bugs will be reported, I commit I'll fix them in the same release cycle.
If both of you agree, I'll amend Linus's v4 patch when applying.
Cheers,
ta
next prev parent reply other threads:[~2023-07-18 3:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 21:59 Linus Walleij
2023-07-13 3:32 ` Tudor Ambarus
2023-07-13 7:01 ` Michael Walle
2023-07-18 3:23 ` Tudor Ambarus [this message]
2023-07-18 6:25 ` Michael Walle
2023-07-18 7:44 ` Tudor Ambarus
2023-07-18 7:50 ` Tudor Ambarus
2023-07-18 8:32 ` Michael Walle
2023-07-18 9:47 ` Tudor Ambarus
2023-07-18 11:58 ` Linus Walleij
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=d99d87e7-47ba-d6fe-735f-16de2a2ec280@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@walle.cc \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--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
all inboxes | Powered by JetHome®