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

[Adrian Hunter]

On 20/03/2026 18:47, 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

If it works on 4.9 but does not work on 4.10, we would normally
git bisect to find the first commit where it fails.  In that way
we may find the root cause and can then design a fix.

>   - 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

Later you have said INT33BB is not related.  Are there error
messages for 0000:00:12.0 ?  What are the symptoms of the failure?

Note the GPIO driver should be /sys/bus/platform/drivers/cherryview-pinctrl
Does that have any devices listed?

> 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

If an ACPI node has an _HID, then it might be enumerated as a
platform device, and driven by a platform driver (like sdhci-acpi),
but not if _STA (status) is 0 (not present).

PCI devices are enumerated by the PCI bus, but the ACPI node is
associated with an existing device via _ADR.  In this case
0000:00:12.0 has an ACPI companion node "SDHC" as identified by
_ADR = 0x00120000.  Unless kernel command line option acpi=strict
is used, Linux does not care about _STA for that purpose.

BIOS can hide PCI devices from PCI enumeration, so the PCI device
would not be visible at all if the intention was that it should
be driven as an ACPI device.

> 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.

Documented where?

> 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.

For the upstream kernel, the expectation is that a fix addresses the
underlying problem.  At the moment it is not clear what that is.