qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: "Bin Meng" <bmeng.cn@gmail.com>, QEMU <qemu-devel@nongnu.org>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-stable <qemu-stable@nongnu.org>
Subject: Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0
Date: Wed, 19 Nov 2025 08:31:21 -0600	[thread overview]
Message-ID: <20251119143121.GZ2125796@bill-the-cat> (raw)
In-Reply-To: <88dae27a-e6c1-4c83-8b89-0f1d8bda4dd0@tls.msk.ru>

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

On Wed, Nov 19, 2025 at 01:44:47PM +0300, Michael Tokarev wrote:
> On 11/10/25 14:05, Bin Meng wrote:
> > 
> > The U-Boot community reported a CI failure [1] where the
> > `sifive_unleashed` target failed to boot from an SD card after
> > upgrading from QEMU v8.2.0 to v9.2.3.
> > 
> > At that time, the issue was traced to commit da954d0e
> > ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
> > which was introduced in v9.1.0.
> > 
> > Testing with the latest QEMU mainline shows that the problem still
> > persists, although the underlying cause has changed due to refactoring
> > since then.
> > 
> > This series fixes the broken `ssi-sd` model. After applying these
> > patches, U-Boot successfully boots again on the `sifive_unleashed`
> > target using QEMU’s `sifive_u` machine.
> > 
> > [1] https://gitlab.com/qemu-project/qemu/-/issues/2945
> 
> Hi!
> 
> This seems to be a qemu-stable material.
> 
> The refactoring mentioned above happened between 10.1.0-rc1 and
> 10.1.0-rc2, which is quite a hot spot for a refactoring.   So the
> changes are definitely relevant for 10.1.x series, where I applied
> them already.
> 
> But we've 10.0.x series which supposed to be long-term support
> series, where we have the problem too (since the issue were
> introduced before 10.0), but the 2 fixes here don't apply to 10.0,
> obviously, due to refactoring.
> 
> Now I wonder should we fix this in 10.0.x at all, should we
> create some unique fix for 10.0.x, or should we pick the
> refactoring done in 10.1.0-rc stage, to 10.0.x?
> 
> This is the original refactoring patchset:
> https://lore.kernel.org/qemu-devel/20250804133406.17456-1-philmd@linaro.org/
> 
> The patchset applies cleanly to 10.0.x, with these 2 fixes on
> top, and the resulting thing seem to work fine, so far anyway:
> https://gitlab.com/mjt0k/qemu/-/commits/10.0-sdcard
> (and with local tests, including the test in the above series).
> 
> What do you think?  How important it is to make this whole
> thing work in 10.0.x lts series (including distribution(s)
> based on this, such as current debian stable "trixie")?

With my U-Boot hat on (which is where we found the issue), it's not
critical. I need to get us in the habit of "do a release, upgrade
ancillary tooling we test too" so that we find potential problems like
this much quicker. We should be, but aren't, on 10.1.x already for
v2026.04 and on 10.0.6 not 10.0.2 for v2026.01.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      parent reply	other threads:[~2025-11-19 14:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-10 11:05 [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0 Bin Meng
2025-11-10 11:05 ` [PATCH 1/2] hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode Bin Meng
2025-11-12  7:55   ` Philippe Mathieu-Daudé
2025-11-10 11:05 ` [PATCH 2/2] hw/sd: Fix ACMD41 state machine in " Bin Meng
2025-11-18 18:19   ` Philippe Mathieu-Daudé
2025-11-10 11:57 ` [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0 Philippe Mathieu-Daudé
2025-11-10 13:16   ` Bin Meng
2025-11-18 18:19 ` Philippe Mathieu-Daudé
2025-11-19 10:44 ` Michael Tokarev
2025-11-19 10:52   ` Michael Tokarev
2025-11-19 14:31   ` Tom Rini [this message]

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=20251119143121.GZ2125796@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=bmeng.cn@gmail.com \
    --cc=mjt@tls.msk.ru \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).