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

Nelson Johnson
2026-03-21T15:25:09Z

On Sat, Mar 21, 2026 at 12:17:42PM +0100, Hans de Goede wrote:
> Can you try running:
> ls -ld /sys/bus/pci/devices/0000:00:12.0/firmware_node
> and if that exists do:
> cat /sys/bus/pci/devices/0000:00:12.0/firmware_node/status
> I wonder if the PCI "slot" does have a ACPI companion-node
> and if that has a status attribute, and if yes to both what
> the status attribute says.

Done. Results below, collected on Debian vanilla, Fedora Live
without Secure Boot, and Fedora Live with Secure Boot enabled.
The results are identical across all three.

firmware_node:

ls -ld /sys/bus/pci/devices/0000:00:12.0/firmware_node
lrwxrwxrwx 1 root root 0
/sys/bus/pci/devices/0000:00:12.0/firmware_node ->
../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/80860F14:01

cat /sys/bus/pci/devices/0000:00:12.0/firmware_node/status
0

ACPI device status (identical across all three boot environments):

80860F14:00 status: 15 (eMMC controller, working)
80860F14:01 status: 0 (SD slot companion, disabled)
INT33BB:00 status: 15 (present)

Identity of 80860F14:01:

hid: 80860F14
uid: 3
path: \_SB_.PCI0.SDHC
adr: 0x00120000
hrv: 1
physical_node -> ../../../../pci0000:00/0000:00:12.0

Identity of INT33BB:00 for comparison:

hid: INT33BB
uid: 2
path: \_SB_.PCI0.SDHB
adr: 0x00110000
hrv: 2

The adr fields are notable. 80860F14:01 has adr 0x00120000 which
maps to PCI 00:12.0, the SD slot. INT33BB:00 has adr 0x00110000
which maps to PCI 00:11.0, a different device. INT33BB:00 does
not appear to be the ACPI companion for the SD slot.

80860F14:01 at path \_SB_.PCI0.SDHC with physical_node pointing
directly to 0000:00:12.0 appears to be the correct disabled
companion for the SD slot.

Regarding the BIOS mode test: the N22 was booted into Fedora
Workstation 41 Live both with Secure Boot disabled and with
Secure Boot enabled. In the Secure Boot run, dmesg confirmed:

secureboot: Secure boot enabled
Kernel is locked down from EFI Secure Boot mode
integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA
2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'

I did not observe any BIOS mode switch. The ACPI device status
values were identical across all three boot environments.

Fedora dmesg shows the same broken sequence as Debian vanilla:

[ 14.272600] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
[ 14.285627] mmc1: SDHCI controller on ACPI [80860F14:00] using ADMA
[ 14.375047] sdhci-pci 0000:00:12.0: SDHCI controller found [8086:2296] (rev 21)
[ 14.456554] mmc0: Failed to initialize a non-removable card
[ 14.457130] mmc1: new HS200 MMC card at address 0001
... sdhci-pci 0000:00:12.0 repeating, BusMaster- throughout

The full acpidump (233KB) is available at:

https://pastebin.com/PVmW1Lkr

Given that 80860F14:01 is present with physical_node pointing to
0000:00:12.0 but disabled with status 0, would enabling it via
the override_status_id mechanism in drivers/acpi/x86/utils.c be
the right direction? And would that alone be sufficient to let
the correct ACPI path own the SD slot, or would INT33BB:00 still
need to be handled separately?