lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <mafs01prbvbjm.fsf@kernel.org>
Date: Sun, 22 Jun 2025 21:09:01 +0200
From: Pratyush Yadav <pratyush@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Tudor Ambarus <tudor.ambarus@...aro.org>,  Pratyush Yadav
 <pratyush@...nel.org>,  Cheng Ming Lin <chengminglin@...c.com.tw>,  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, Linus Torvalds
 <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2 1/3] mtd: spi-nor: macronix: Drop the redundant flash
 info fields

Hi Guenter,

On Tue, Jun 10 2025, Guenter Roeck wrote:

> 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:
[...]
>>>>>> 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.
>>>>
[...]
>
> 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.

I used the command you posted in [0] and tried to reproduce the bug, but
for me the flash probes just fine:

    root@...ulus:/sys/bus/spi/devices/spi0.0/spi-nor# cat manufacturer 
    macronix
    root@...ulus:/sys/bus/spi/devices/spi0.0/spi-nor# cat jedec_id 
    c22019
    root@...ulus:/sys/bus/spi/devices/spi0.0/spi-nor# uname -a
    Linux romulus 6.16.0-rc2-00308-gf7301f856d35-dirty #5 SMP Sat Jun 21 19:29:15 CEST 2025 armv6l GNU/Linux

The rootfs is also mounted on a mtdblock device backed by this flash,
and everything appears to work fine.

Which version of qemu are you using? I can see that SFDP data for
mx25l25635e was added to qemu in commit dc907a667c ("m25p80: Add the
mx25l25635e SFPD table"), which was released in v7.2.0. Older versions
of qemu might run into trouble with this flash if SFDP data is not
available.

FWIW, my qemu version:

    $ qemu-system-arm --version
    QEMU emulator version 10.0.0
    Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers

[0] https://lore.kernel.org/linux-mtd/da58fc81-3c99-4951-85bc-e3c139283b5a@roeck-us.net/

-- 
Regards,
Pratyush Yadav

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ