ACPI: enumeration of devices declaring only _CID (no _HID/_ADR)

ACPI: enumeration of devices declaring only _CID (no _HID/_ADR)

[benoit]

Hi,

On an Acer One 10 S1003 (Intel Atom x5-Z8350, Cherry Trail, Insyde BIOS V1.19)
the internal SDIO WiFi is never enumerated by Linux, while it works under
Windows. The root cause is a firmware bug, but I would like to ask whether the
kernel could reasonably be more lenient about it.

The SDIO host controller the WiFi chip sits on is declared like this:

    Device (SDHB)
    {
        Name (WADR, Zero)
        Name (WHID, "80860F14")
        Name (AHID, "INT33BB")
        Name (_CID, "PNP0D40")
        Name (_DDN, "Intel(R) SDIO Controller - 80862295")
        Name (_UID, 0x02)
        ...
        Method (_STA, 0, NotSerialized)
        {
            If (((SI0A == Zero) || (SD2D == One))) { Return (Zero) }
            Return (0x0F)
        }
        Method (_CRS, 0, NotSerialized) { ... }   /* valid MMIO + IRQ */
    }

It declares neither _HID nor _ADR, only _CID. Its two siblings SDHA (eMMC) and
SHC1 (SD card) both declare _HID "80860F14" and are enumerated normally.

iasl flags it when recompiling the untouched table:

    DSDT.dsl 9134:  Device (SDHB)
    Error 6141 - Missing dependency ^ (Device object requires a _HID or _ADR)

So this is firmware violating the spec. The node is otherwise complete and
functional: _STA returns 0x0F, and _CRS returns a valid MMIO range plus IRQ.

What happens on Linux: acpi_set_pnp_ids() sets pnp->type.platform_id only in
the ACPI_VALID_HID branch, never for _CID. acpi_bus_attach() then calls
acpi_default_enumeration() only when platform_id is set, so no platform device
is created. sdhci-acpi is never probed, no MMC host is created, the SDIO bus is
never scanned and brcmfmac never loads. The device is visible in sysfs with
hid=PNP0D40 (taken from _CID) and status=15, but with no physical_node and no
driver bound:

    $ cat /sys/bus/acpi/devices/PNP0D40:00/status
    15
    $ ls /sys/bus/acpi/devices/PNP0D40:00/
    device:1e  device:1f  hid  modalias  path  power  power_state  status
    subsystem  uevent  uid
    (no physical_node, no driver)

sdhci-acpi does list PNP0D40 in both sdhci_acpi_ids[] and sdhci_acpi_uids[], so
it would have bound had a platform device existed.

Adding "Name (_HID, \"80860F14\")" to that node via a patched DSDT loaded
through CONFIG_ACPI_TABLE_UPGRADE is sufficient to make it work: sdhci-acpi
binds, the SDIO card is found, brcmfmac loads and the interface comes up.
(The _HID value is not invented: the node already carries WHID = "80860F14"
alongside AHID = "INT33BB", evidently its "Windows" and "Android" identities,
and its existing _UID = 2 maps to sdhci_acpi_slot_int_sdio, which is correct.)

    mmc2: SDHCI controller on ACPI [80860F14:01] using ADMA
    mmc2: new high speed SDIO card at address 0001
    brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430a0-sdio
              for chip BCM43430/0

My question: would it be acceptable for acpi_default_enumeration() to fall back
to _CID when a device declares no _HID and no _ADR but does have _STA and _CRS?
Windows evidently enumerates such nodes, and a DSDT override is a heavy
workaround to ask of users for what is a single missing name in the firmware.

I appreciate there may be good reasons not to relax this, in which case please
treat the report as documentation of the failure mode: it is silent, with no
error anywhere in dmesg, and took a full DSDT disassembly to find.

I am happy to test patches on this hardware.

Reported on 6.14.0-35-generic (Ubuntu/Mint), but the relevant logic in
drivers/acpi/scan.c is unchanged in current mainline.