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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

+Cc: Hans

On Fri, Mar 20, 2026 at 11:47:53AM -0500, Nelson Johnson wrote:
> 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.

I believe Adrian added me to the Cc list to hear my opinion as I heard
about Bay Trail and similar machines more often than him nowadays. Yet
I am not working directly with them much, Hans does (or at least recently
did a lot). Nevertheless, looking briefly into the series and this message
I kinda tend to agree to make patches go in. We have tons of Bay Trail
machines from recent years and they are still supported well enough by
vanilla kernel (thanks to Hans).

TL;DR: I can look a bit closer and review the patches.

P.S.
I have installed a home router last year based on Bay Trail :-)


-- 
With Best Regards,
Andy Shevchenko