Re: [PATCH 1/6] Revert "spi: zynq_qspi: Add parallel memories support in QSPI driver"

[Jon Humphreys <j-humphreys@ti.com>]

Marek Vasut <marek.vasut@mailbox.org> writes:

> On 10/23/24 10:17 AM, Michal Simek wrote:
>> 
>> 
>> On 10/22/24 23:06, Marek Vasut wrote:
>>> This reverts commit 1e36d34b52e7a1ebe5a2a5339d6905540f4253aa.
>>>
>>> This parallel/stacked support breaks basic SPI NOR support,
>>> e.g. this no longer works:
>>>
>>> => sf probe && sf update 0x50000000 0 0x160000
>>> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, 
>>> total 64 MiB
>>> device 0 offset 0x0, size 0x160000
>>> SPI flash failed in read step
>> 
>> Reverting everything seems to me too much. Tom has tested it on his HW 
>> and didn't see any issue. That's why better to look at code which is 
>> causing this.
>> You are reverting everything but likely there is specific patch which is 
>> causing this. Which one is it?
>> Which board was used for your testing? Likely we don't have access to it.
>> Is there any QEMU available which can be used for debugging?
>
> The testcase including the exact SPI NOR model is above.
>
> iMX6 with w25q16dw seems to be broken too.
>
> Basically every board I have access no longer has a working "sf probe ; 
> sf update" combination ... so yeah, this means this patchset is 
> fundamentally broken.
>

I can also confirm that the patch series:

f8efc68b30e Merge patch series "spi-nor: Add parallel and stacked memories
support"

breaks SPI NOR on TI platforms, particularly SK-AM62 and SK-AM62P:

U-Boot 2024.10-00752-gf8efc68b30e2 (Nov 06 2024 - 12:25:13 -0600)

SoC:   AM62X SR1.0 HS-FS
Model: Texas Instruments AM625 SK
...
Hit any key to stop autoboot:  0
=> sf probe && sf update ${loadaddr} 0x400000 0x10
SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB
device 0 offset 0x400000, size 0x10
SPI flash failed in read step
=>

Jon

>>> Since none of this seems to be in Linux either, revert it all.
>> 
>> This has been discussed with Tom before.
>
> Tom is not the U-Boot MTD maintainer ?
>
>> It wasn't in sync even before 
>> and we can't really stop development on subsystems.
> These patches have been rejected from mainline Linux for many years, why 
> are they added to U-Boot which includes an import of MTD subsystem from 
> Linux ? Such diverging code base with random patches will only make it 
> much harder to synchronize Linux MTD subsystem back to U-Boot.