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

Nelson Johnson
2026-03-20T23:07:12Z

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.