[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff485da8-1a02-40a9-9286-94459e52b26c@roeck-us.net>
Date: Tue, 10 Jun 2025 00:41:32 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Tudor Ambarus <tudor.ambarus@...aro.org>,
Pratyush Yadav <pratyush@...nel.org>,
Cheng Ming Lin <chengminglin@...c.com.tw>
Cc: Cheng Ming Lin <linchengming884@...il.com>, mwalle@...nel.org,
miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
alvinzhou@...c.com.tw, leoyu@...c.com.tw
Subject: Re: [PATCH v2 1/3] mtd: spi-nor: macronix: Drop the redundant flash
info fields
On 6/9/25 23:46, Tudor Ambarus wrote:
>
>
> On 6/10/25 1:14 AM, Guenter Roeck wrote:
>> On 6/8/25 18:13, Guenter Roeck wrote:
>>> On 6/8/25 05:53, Pratyush Yadav wrote:
>>>> On Sat, Jun 07 2025, Guenter Roeck wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Mon, Apr 07, 2025 at 03:53:58PM +0800, Cheng Ming Lin wrote:
>>>>>> From: Cheng Ming Lin <chengminglin@...c.com.tw>
>>>>>>
>>>>>> Many flash devices share the same ID but have different part numbers.
>>>>>> To avoid confusion, the part number field is removed.
>>>>>>
>>>>>> Additionally, since SFDP already provides size information and
>>>>>> functionality covered by no_sfdp_flags, these fields are also removed.
>>>>>>
>>>>>> Furthermore, when 4-byte address instruction table is available,
>>>>>> the SPI_NOR_4B_OPCODES flag is no longer needed and is removed.
>>>>>>
>>>>>> Signed-off-by: Cheng Ming Lin <chengminglin@...c.com.tw>
>>>>>> Acked-by: Tudor Ambarus <tudor.ambarus@...aro.org>
>>>>>
>>>>> With this patch in place, some of my qemu tests no longer recognize the
>>>>> flash chips (MX25L25635E/F). Do you have a suggestion on how to handle
>>>>> this other than avoiding Macronix flash chips when working with qemu ?
>>>>
>>>> Could you share some logs? Does the flash fail to detect, or does the
>>>> SFDP-based probing fail? Since this is qemu, it would be even better if
>>>> you can share a setup/reproduction guide. I have been meaning to set up
>>>> qemu for SPI NOR testing for some time now, but never got around to
>>>> figuring it out.
>>>>
>>>
>>> I suspect that the SFDP data for the affected flashes is incorrect in
>>> qemu.
>>> Since this is very likely a qemu problem, I'll just configure
>>> different flash
>>> chips when running affected tests.
>>>
>>
>> I was able to confirm the above. This is from the kernel log:
>>
>> [ 4.500000] spi-nor spi0.0: BFPT parsing failed. Please consider
>> using SPI_NOR_SKIP_SFDP when declaring the flash
>> [ 4.500000] spi-nor spi0.0: probe with driver spi-nor failed with
>> error -22
>>
>
> It's likely the problem where the same flash ID is used for different
> flavors of flashes. Typically we differentiate the flavors by comparing
> their SFDP data and use post SFDP hooks to amend where needed. If no one
> cares about fixing it, we can undo the change for the affected flash or
> revert the patch entirely. Cheng?
>
Some debugging shows two problems with qemu: The returned SFPD data for one
of the flashes is wrong and does not reflect the data qemu is supposed
to provide, and qemu does not provide SFPD data for all flashes.
I don't know if the bad data is due to a bad Linux driver (unlikely), a bug
in qemu's SPI emulation code, or a bug in qemu's flash emulation code.
Unfortunately I don't really have time to track this down further.
Guenter
Powered by blists - more mailing lists