From: Pratyush Yadav <pratyush@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexander Usyskin <alexander.usyskin@intel.com>,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: Linux 6.16-rc1
Date: Sat, 21 Jun 2025 14:44:32 +0200 [thread overview]
Message-ID: <mafs08qlluuvj.fsf@kernel.org> (raw)
In-Reply-To: <CAHk-=whDM950+cCgmNH2edB2edCaktdpvBLGjFESAZfYZ3ZpRQ@mail.gmail.com>
Hi Linus,
On Fri, Jun 20 2025, Linus Torvalds wrote:
> On Tue, 10 Jun 2025 at 18:25, Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> The test failures are all due to commit 0aa7b390fc40 ("mtd: core: always
>> create master device") which breaks mtd partitioning.
>
> Ok, I just merged the pull request that reverted that one.
>
>> One side note: Various qemu machines configured to use Macronix flash chips
>> are no longer able to access the chips. This is primarily due to commit
>> 947c86e481a0 ("mtd: spi-nor: macronix: Drop the redundant flash info
>> fields"). After that change, SFDP support for affected chips is mandatory,
>> and qemu does not or not correctly support that. This affects quanta-gsj,
>> kudo-bmc, ast2600-evb, and supermicro-x11spi-bmc machines (and possibly
>> others).
>
> .. but this issue presumably remains, unless there's been some subtler
> indirect fix that I didn't realize.
>
> Miguel, that one came through you too. Comments? I do think that
> running things in qemu is likely important for a lot of these things
> that don't actually have a ton of hardware that is easily automated...
There isn't a fix AFAIK. From the thread [0], there seemed to be a
conclusion that it was a qemu problem and not directly a problem on the
driver side. So I dropped this down my list of priorities of things to
look into.
I don't have much idea of how people use qemu for testing, but since you
say this is important for testing workloads, I can take a deeper dive
next week and have an answer by -rc4.
[0] https://lore.kernel.org/linux-mtd/8d4bd876-3571-46e5-857a-948e58b21c5b@roeck-us.net/
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-06-21 12:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-08 21:17 Linux 6.16-rc1 Linus Torvalds
2025-06-11 1:25 ` Guenter Roeck
2025-06-21 5:42 ` Linus Torvalds
2025-06-21 12:44 ` Pratyush Yadav [this message]
2025-06-21 15:59 ` Linus Torvalds
2025-06-23 0:39 ` Guenter Roeck
2025-06-23 11:17 ` Pratyush Yadav
2025-06-23 13:47 ` Guenter Roeck
2025-06-11 5:55 ` linux-next: stats (Was: Linux 6.16-rc1) Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mafs08qlluuvj.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=alexander.usyskin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=miquel.raynal@bootlin.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.