[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8d4bd876-3571-46e5-857a-948e58b21c5b@roeck-us.net>
Date: Tue, 10 Jun 2025 00:43:40 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Cheng Ming Lin <linchengming884@...il.com>,
Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: Pratyush Yadav <pratyush@...nel.org>,
Cheng Ming Lin <chengminglin@...c.com.tw>, 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/10/25 00:29, Cheng Ming Lin wrote:
> Tudor Ambarus <tudor.ambarus@...aro.org> 於 2025年6月10日 週二 下午2:46寫道:
>>
>>
>>
>> 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?
>>
>
> Since this patch removed the size field, the issue occurs because the
> "spi_nor_init_params" function now processes the "spi_nor_parse_sfdp"
> function. As a result, the error is likely caused by a problem during the
> SFDP parsing, which leads to the failure of "spi_nor_init_params".
>
> The issue can be resolved by adding .size = SZ_32M to the flash_info for
> MX25L25635E to prevent failures caused by SFDP parsing.
>
> The root cause of this problem lies in the failure of parsing the SFDP
> data for the flash, rather than an issue with the patch itself. I believe
> we should not revert this patch.
>
I tend to agree. The problem is very likely on the qemu side and should be
addressed there.
Guenter
Powered by blists - more mailing lists