Re: [PATCH 0/3] mmc: Lenovo N22 Braswell SD slot fixes

[Nelson Johnson]

On Fri, Mar 20, 2026 at 8:27 AM Adrian Hunter wrote:
> These changes seem more like they work around the problem rather
> than fix the problem, but you say it worked OK in v4.14? I see also
> mention of v4.9 in patch 1? When it was working, was it using the ACPI
> driver or the PCI driver?

You are right that this series is a workaround for a firmware-specific
problem rather than a generic root-cause fix.

My confirmed working baseline is v4.9, and on that kernel the
controller was owned by sdhci-pci, not sdhci-acpi. The INT33BB:00
ACPI node was present in firmware but did not prevent the PCI path
from working. I should have been more precise in the cover letter.
What I can state from testing is:

  - v4.9: slot works via sdhci-pci
  - current kernels: slot is unusable
  - current kernels with this series applied: slot works again via sdhci-pci

> In patch 3, you say the SDHCI ACPI driver repeatedly defers. Is that
> because it is waiting for the GPIO driver for the Card Detect GPIO?

Yes. On this machine INT33BB:00 defers waiting for the card-detect
GPIO dependency, and that dependency never becomes available. In the
broken state the ACPI path does not successfully probe and the slot
remains unusable. Excluding INT33BB:00 on this DMI match allows
sdhci-pci to own 0000:00:12.0 and restores card detection.

I am not aware of an existing generic ownership-arbitration mechanism
between sdhci-acpi and sdhci-pci for this dual-enumerated firmware
layout, so I chose the narrowest fix available: a DMI-scoped exclusion
on the affected machine only. That approach is consistent with how the
subsystem has handled similar firmware defects elsewhere. sdhci-acpi.c
already carries a maintained quirk table covering the Lenovo Miix 320,
Acer Aspire Switch 10, Lenovo Yoga Tablet 2 Pro, Toshiba Encore 2, and
ASUS T100TA, all firmware defects fixed with DMI scope and accepted
with stable tags. sdhci-pci-core.c follows the same pattern, as
jsl_broken_hs400es() immediately above the new helper demonstrates.

> Note Lenovo N22 seems to date back to 2017. Is it really worth
> spending time on something that old, especially as no one seems
> to have worried about it before?

My argument for upstream is mainly that the quirk is small and
low-risk, and that PCI ID 8086:2296 is part of the wider Braswell SD
controller family rather than unique to this one machine. Although the
Lenovo N22 is an older platform, Braswell systems remain in active
secondary use. The Lenovo IdeaPad 100S-14IBR carries the same
controller and has a documented bug report showing sdhci-pci not
binding on kernel 4.10 after working on 4.8, the same symptom pattern.
The commit documents the failure mode, the correct driver ownership
decision, and the workaround approach in a place where anyone dealing
with a similar Braswell platform can find and reference it.

That said, I defer to your judgment on whether this serves value to
the wider community. I am happy to carry it as a local patch if you
feel it does not belong upstream.