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

[Nelson Johnson]

On Fri, Mar 20, 2026 at 07:08:41PM +0100, Andy Shevchenko wrote:
> Can you share ACPI DSDT excerpt (from DSDT table of firmware, you can
> get it by copying file from /sys/firmware/acpi/tables/DSDT and decode
> it with `iasl -d DSDT`) and output of `lspci -vv -n -s $SDHCI_SLOT`?
> Because it might be that the problem should be solved just by providing
> better fixes to GPIO detection or so.

Here is the requested data collected from the N22 on a vanilla
6.19.6+deb14+1-amd64 kernel with no patches applied.

DSDT INT33BB section (decoded from /sys/firmware/acpi/tables/DSDT):

    Name (_HID, "INT33BB")
    Name (_CID, "PNP0D40")
    Name (_DDN, "Intel(R) SDIO Controller - 80862295")
    Name (_UID, 0x02)
    Name (_HRV, 0x02)
    Name (_DEP, Package (0x01)
    {
        GPO1
    })
    Name (ABUF, ResourceTemplate ()
    {
        Memory32Fixed (ReadWrite, 0x00000000, 0x00001000, _Y04)
        Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive) { 0x0000002E }
        GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly,
            "\\_SB.GPO1", 0x00, ResourceConsumer, ,)
            {
                0x0005
            }
    })
    Method (_PS0, 0, NotSerialized)
    {
        PSAT &= 0xFFFFFFFC
        PSAT |= Zero
        If ((PSTS == Zero))
        {
            If ((^^^GPO1.AVBL == One))
            {
                ^^^GPO1.CWLE = One
            }
            PSTS = One
        }
    }
    Method (_PS3, 0, NotSerialized)
    {
        PSAT |= 0x03
        PSAT |= Zero
    }

Two things stand out in this description. First, the _DDN names the
device as "Intel(R) SDIO Controller - 80862295" rather than an SD
slot, and _UID is 0x02; in current sdhci-acpi.c, INT33BB UID 2 maps
to the SDIO slot profile rather than the removable SD profile. Second,
the GpioIo descriptor for pin 5 on GPO1 is IoRestrictionOutputOnly
with PullNone. My reading of the AML is that this looks more like an
enable/control line than a card-detect input, but that is an inference
from the firmware description rather than something I can prove from
the AML alone.

lspci -vv -n -s 0000:00:12.0 on vanilla kernel:

    00:12.0 0805: 8086:2296 (rev 21) (prog-if 01)
        Subsystem: 17aa:3807
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
                 ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
                >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at 91315000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [80] Power Management version 3
            Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
                   PME(D0+,D1-,D2-,D3hot+,D3cold-)
            Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Kernel modules: sdhci_pci

Note BusMaster- on the vanilla kernel. With the patch series applied
BusMaster+ and Kernel driver in use: sdhci-pci.

Vanilla dmesg for SD/MMC:

    [    3.142590] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
    [    3.155518] mmc1: SDHCI controller on ACPI [80860F14:00] using ADMA
    [    3.356405] mmc0: Failed to initialize a non-removable card
    [    3.358473] sdhci-pci 0000:00:12.0: SDHCI controller found [8086:2296] (rev 21)
    [    3.397615] sdhci-pci 0000:00:12.0: SDHCI controller found [8086:2296] (rev 21)
    ... (repeated approximately 30 times over 30 seconds)
    [   30.066835] sdhci-pci 0000:00:12.0: SDHCI controller found [8086:2296] (rev 21)

The observed sequence on the vanilla kernel is:

  - sdhci-acpi binds INT33BB:00 and creates mmc0
  - mmc0 then fails with "Failed to initialize a non-removable card"
  - sdhci-pci repeatedly reports "SDHCI controller found [8086:2296]"
  - lspci -vv shows BusMaster- and no "Kernel driver in use" line
    for 0000:00:12.0 throughout

That seems consistent with the ACPI path binding the
firmware-described instance while the PCI path never reaches a
usable bound state.

Given the output-only GPIO descriptor and the current non-removable
SDIO mapping for INT33BB UID 2, does this point to a fixable ACPI /
GPIO-enumeration issue, or do you think machine-scoped exclusion of
the ACPI node is still the right direction for this firmware? I am
happy to test any suggested patch or approach on the hardware.