Re: [PATCH] mtd: spi-nor: winbond: Make sure w25q{01,02}jv behave correctly

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Michael,

On 10/09/2025 at 07:28:22 +02, Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote:

> Hi all
>
> On Tue, Sep 9, 2025 at 7:08 PM Raghavendra, Vignesh <vigneshr@ti.com> wrote:
>>
>>
>>
>> On 9/9/2025 5:37 PM, Jagan Teki wrote:
>> > On Tue, Sep 9, 2025 at 3:43 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> On 02/07/2025 at 11:23:13 +02, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>> >>
>> >>> These chips are internally made of two/four dies with linear addressing
>> >>> capabilities to make it transparent to the user that two/four dies were
>> >>> used. There is one drawback however, the read status operation is racy
>> >>> as the status bit only gives the active die status and not the status of
>> >>> the other die. For commands affecting the two dies, it means if another
>> >>> command is sent too fast after the first die has returned a valid
>> >>> status (deviation can be up to 200us), the chip will get corrupted/in an
>> >>> unstable state.
>> >>>
>> >>> The solution adopted here is to iterate manually over all internal
>> >>> dies (which takes about 30us per die) until all are ready. This approach
>> >>> will always be faster than a blind delay which represents the maximum
>> >>> deviation, while also being totally safe.
>> >>>
>> >>> A flash-specific hook for the status register read had to be
>> >>> implemented. Testing with the flash_speed benchmark in Linux shown no
>> >>> difference with the existing performances (using the regular status read
>> >>> core function).
>> >>>
>> >>> As the presence of multiple dies is not filled in these chips SFDP
>> >>> tables (the table containing the crucial information is optional), we
>> >>> need to manually wire the hook.
>> >>>
>> >>> This change is adapted from Linux.
>> >>>
>> >>> Link: https://lore.kernel.org/all/20250110-winbond-6-12-rc1-nor-volatile-bit-v3-1-735363f8cc7d@bootlin.com/
>> >>> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>> >>
>> >> Same question for this one, no feedback for the past 2 months, I'm not
>> >> sure who's supposed to take these, Jagan and Vignesh you are marked M:
>> >> in maintainers, any chances this can get it?
>> >
>> > Unfortunately, I was off quite some-time. Need little bit of time.
>> > Vighnesh is off for years.
>>
>> Thats not true. I dont have access to U-Boot SPI trees. So patches have
>> been flowing through individual "platfor/SoC" maintainers trees
>> unfortunately. Tom picks the patches from TI contributors once
>> me/Nishanth Acks where as AMD/Xlinix bits have been picked up by Michal
>> Simek and so on...
>>
>> Happy to help out if you help to manage a merge window every now and
>> then or just review things. Most of the SPI NOR/NAND follow from linux
>> where its reviewed by set of maintainers and tested (example this one is
>> tested on TI board).
>
> I will go through the patches over the weekend and review them. I will
> prepare a branch
> spi-nor-next and try to ask to test from there
>
> Michael
>
>>
>> > In the meantime, Michael will help in
>> > review but need help on testing.
>> >
>> > Thanks,
>> > Jagan.
>>

I still do not see these patches in any upstream tree. Am I missing
something? If I may, these patches have been reviewed during the Linux
contribution process already, and submission happened in July, almost 5
months ago.

Thanks,
Miquèl