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

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

[Nelson Johnson]

This series fixes the long-broken SD slot on the Lenovo N22
(Model 80S6 / MTM 80S60001US) with Intel Celeron N3050 Braswell
hardware running Debian 13 and Linux 6.19.6.

The regression goes back to kernel 4.14. The Braswell SD controller
(PCI ID 8086:2296) is exposed by firmware through both PCI
0000:00:12.0 and ACPI INT33BB:00 at \_SB_.PCI0.SDHB.

On this machine the newer runtime PM and card-detect handling no
longer works reliably, and the ACPI path permanently defers because
its dependency never becomes available. That leaves the slot unusable
unless the controller is forced back onto the working PCI path with
machine-specific quirks.

This series does three things, all scoped to the Lenovo N22 DMI
match:

1. Disable the aggressive runtime PM/card-detect wake path for the
   Braswell PCI SD controller.
2. Bypass the broken firmware card-detect GPIO path and use polling
   for card insertion detection.
3. Prevent the competing ACPI INT33BB:00 node from binding on this
   machine so the PCI SDHCI driver can own the controller.

With these changes applied, the SD slot binds through sdhci-pci and
detects and mounts SD cards again on the Lenovo N22.

Tested on:
  Lenovo N22 Model 80S6 / MTM 80S60001US
  Intel Celeron N3050 (Braswell)
  Debian 13
  Linux 6.19.6

Nelson Johnson (3):
  mmc: sdhci-pci: disable aggressive runtime PM for Braswell SD on
    Lenovo N22
  mmc: sdhci-pci: force polling card detect for Braswell SD on Lenovo
    N22
  mmc: sdhci-acpi: exclude INT33BB:00 from ACPI binding on Lenovo N22

 drivers/mmc/host/sdhci-acpi.c     | 10 ++++++++++
 drivers/mmc/host/sdhci-pci-core.c | 33 ++++++++++++++++++++++++++-----
 2 files changed, 38 insertions(+), 5 deletions(-)

-- 
2.47.3

[PATCH 1/3] mmc: sdhci-pci: disable aggressive runtime PM for Braswell SD on Lenovo N22

[Nelson Johnson]

Lenovo N22 systems with the Braswell SD controller (PCI ID 8086:2296) regress on kernels newer than 4.9. On this machine the SD slot is exposed through both PCI and ACPI firmware nodes, and enabling the newer aggressive runtime PM/card-detect wake path causes the controller to stop behaving like the older working configuration.

Keep the Lenovo N22 on the pre-4.14 behavior by skipping MMC_CAP_AGGRESSIVE_PM and MMC_CAP_CD_WAKE for the 8086:2296 slot on this DMI match, and disable runtime PM for that host.

This preserves the rest of the Braswell/Atom handling while restoring the power-management behavior that allows the slot to function on the Lenovo N22.

Fixes: 6cf4156c0988 ("mmc: sdhci-pci: Enable card detect wake for Intel BYT-related SD controllers")
Signed-off-by: Nelson Johnson <nzjfr547@gmail.com>
---
 drivers/mmc/host/sdhci-pci-core.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 47a0a7388..4b3c61609 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -923,6 +923,13 @@ static bool jsl_broken_hs400es(struct sdhci_pci_slot *slot)
 			dmi_match(DMI_BIOS_VENDOR, "ASUSTeK COMPUTER INC.");
 }
 
+static bool sdhci_pci_is_lenovo_n22_bsw_sd(struct sdhci_pci_slot *slot)
+{
+	return slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BSW_SD &&
+	       dmi_match(DMI_SYS_VENDOR, "LENOVO") &&
+	       dmi_match(DMI_BOARD_NAME, "N22");
+}
+
 static int glk_emmc_probe_slot(struct sdhci_pci_slot *slot)
 {
 	int ret = byt_emmc_probe_slot(slot);
@@ -1120,9 +1127,13 @@ static void byt_needs_pwr_off(struct sdhci_pci_slot *slot)
 
 static int byt_sd_probe_slot(struct sdhci_pci_slot *slot)
 {
+	bool runtime_pm_ok = !sdhci_pci_is_lenovo_n22_bsw_sd(slot);
+
 	byt_probe_slot(slot);
-	slot->host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY |
-				 MMC_CAP_AGGRESSIVE_PM | MMC_CAP_CD_WAKE;
+	slot->host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY;
+	if (runtime_pm_ok)
+		slot->host->mmc->caps |= MMC_CAP_AGGRESSIVE_PM |
+					 MMC_CAP_CD_WAKE;
 	slot->cd_idx = 0;
 	slot->cd_override_level = true;
 	if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BXT_SD ||
@@ -1135,7 +1146,10 @@ static int byt_sd_probe_slot(struct sdhci_pci_slot *slot)
 	    slot->chip->pdev->subsystem_device == PCI_SUBDEVICE_ID_NI_78E3)
 		slot->host->mmc->caps2 |= MMC_CAP2_AVOID_3_3V;
 
-	byt_needs_pwr_off(slot);
+	if (runtime_pm_ok)
+		byt_needs_pwr_off(slot);
+	else
+		slot->chip->allow_runtime_pm = false;
 
 	return 0;
 }
-- 
2.47.3

Re: [PATCH 1/3] mmc: sdhci-pci: disable aggressive runtime PM for Braswell SD on Lenovo N22

[Andy Shevchenko]

On Mon, Mar 16, 2026 at 04:23:23PM -0500, Nelson Johnson wrote:
> Lenovo N22 systems with the Braswell SD controller (PCI ID 8086:2296) regress on kernels newer than 4.9.

v4.9

> On this machine the SD slot is exposed through both PCI and ACPI firmware nodes, and enabling the newer aggressive runtime PM/card-detect wake path causes the controller to stop behaving like the older working configuration.
> 
> Keep the Lenovo N22 on the pre-4.14 behavior by skipping MMC_CAP_AGGRESSIVE_PM and MMC_CAP_CD_WAKE for the 8086:2296 slot on this DMI match, and disable runtime PM for that host.
> 
> This preserves the rest of the Braswell/Atom handling while restoring the power-management behavior that allows the slot to function on the Lenovo N22.

When creating the commit message you need to wrap the lines around ~72
characters per line.

-- 
With Best Regards,
Andy Shevchenko

[PATCH 2/3] mmc: sdhci-pci: force polling card detect for Braswell SD on Lenovo N22

[Nelson Johnson]

The Lenovo N22 uses the Braswell SD controller at PCI ID 8086:2296, but its firmware exposes a broken card-detect path. On modern kernels the slot repeatedly fails to come up because the normal GPIO card-detect path never becomes usable on this machine.

Force the Lenovo N22 to skip the firmware GPIO card-detect path for the Braswell SD slot and use polling instead. This keeps the quirk tightly scoped to the affected DMI match while leaving the default behavior unchanged on other Braswell systems.

With the polling fallback in place, the PCI SDHCI path can detect card insertion reliably again on the Lenovo N22.

Fixes: 6cf4156c0988 ("mmc: sdhci-pci: Enable card detect wake for Intel BYT-related SD controllers")
Signed-off-by: Nelson Johnson <nzjfr547@gmail.com>
---
 drivers/mmc/host/sdhci-pci-core.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index 4b3c61609..05ab17e72 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -1134,8 +1134,17 @@ static int byt_sd_probe_slot(struct sdhci_pci_slot *slot)
 	if (runtime_pm_ok)
 		slot->host->mmc->caps |= MMC_CAP_AGGRESSIVE_PM |
 					 MMC_CAP_CD_WAKE;
-	slot->cd_idx = 0;
-	slot->cd_override_level = true;
+	if (!runtime_pm_ok) {
+		/*
+		 * Lenovo N22 Braswell card-detect bypass: ignore the broken
+		 * firmware GPIO path and poll the slot instead.
+		 */
+		slot->cd_idx = -1;
+		slot->host->mmc->caps |= MMC_CAP_NEEDS_POLL;
+	} else {
+		slot->cd_idx = 0;
+		slot->cd_override_level = true;
+	}
 	if (slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BXT_SD ||
 	    slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_BXTM_SD ||
 	    slot->chip->pdev->device == PCI_DEVICE_ID_INTEL_APL_SD ||
-- 
2.47.3

[PATCH 3/3] mmc: sdhci-acpi: exclude INT33BB:00 from ACPI binding on Lenovo N22

[Nelson Johnson]

On the Lenovo N22, the firmware exposes the Braswell SD controller through both PCI 0000:00:12.0 and ACPI INT33BB:00. The ACPI path for INT33BB:00 never finishes probing on this machine and repeatedly defers, which leaves the slot in the broken ACPI path instead of letting the working PCI path own the controller.

Return -ENODEV early for INT33BB:00 on the Lenovo N22 so that sdhci-acpi does not bind this machine-specific firmware node. That leaves the controller to the PCI SDHCI driver, which is the path that works once the N22-specific runtime PM and card-detect quirks are applied.

Scope the exclusion to the Lenovo N22 DMI match so other INT33BB systems continue to use the normal ACPI handling.

Fixes: 6cf4156c0988 ("mmc: sdhci-pci: Enable card detect wake for Intel BYT-related SD controllers")
Signed-off-by: Nelson Johnson <nzjfr547@gmail.com>
---
 drivers/mmc/host/sdhci-acpi.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 84c705460..3badf1c87 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -814,6 +814,12 @@ static const struct sdhci_acpi_slot *sdhci_acpi_get_slot(struct acpi_device *ade
 	return NULL;
 }
 
+static bool sdhci_acpi_is_lenovo_n22(void)
+{
+	return dmi_match(DMI_SYS_VENDOR, "LENOVO") &&
+	       dmi_match(DMI_BOARD_NAME, "N22");
+}
+
 static int sdhci_acpi_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -834,6 +840,10 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
 	if (id)
 		quirks = (long)id->driver_data;
 
+	if (sdhci_acpi_is_lenovo_n22() &&
+	    acpi_dev_hid_uid_match(device, "INT33BB", "2"))
+		return -ENODEV;
+
 	slot = sdhci_acpi_get_slot(device);
 
 	/* Power on the SDHCI controller and its children */
-- 
2.47.3

Re: [PATCH 3/3] mmc: sdhci-acpi: exclude INT33BB:00 from ACPI binding on Lenovo N22

[Andy Shevchenko]

On Mon, Mar 16, 2026 at 04:23:25PM -0500, Nelson Johnson wrote:
> On the Lenovo N22, the firmware exposes the Braswell SD controller through both PCI 0000:00:12.0 and ACPI INT33BB:00. The ACPI path for INT33BB:00 never finishes probing on this machine and repeatedly defers, which leaves the slot in the broken ACPI path instead of letting the working PCI path own the controller.
> 
> Return -ENODEV early for INT33BB:00 on the Lenovo N22 so that sdhci-acpi does not bind this machine-specific firmware node. That leaves the controller to the PCI SDHCI driver, which is the path that works once the N22-specific runtime PM and card-detect quirks are applied.
> 
> Scope the exclusion to the Lenovo N22 DMI match so other INT33BB systems continue to use the normal ACPI handling.

This should be done somewhere in drivers/acpi/x86/lpss.c I believe. That's the
driver that responsible for ACPI enumeration of LPSS devices on Braswell
machines.



-- 
With Best Regards,
Andy Shevchenko

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

[Adrian Hunter]

On 16/03/2026 23:23, Nelson Johnson wrote:
> This series fixes the long-broken SD slot on the Lenovo N22
> (Model 80S6 / MTM 80S60001US) with Intel Celeron N3050 Braswell
> hardware running Debian 13 and Linux 6.19.6.
> 
> The regression goes back to kernel 4.14. The Braswell SD controller
> (PCI ID 8086:2296) is exposed by firmware through both PCI
> 0000:00:12.0 and ACPI INT33BB:00 at \_SB_.PCI0.SDHB.
> 
> On this machine the newer runtime PM and card-detect handling no
> longer works reliably, and the ACPI path permanently defers because
> its dependency never becomes available. That leaves the slot unusable
> unless the controller is forced back onto the working PCI path with
> machine-specific quirks.
> 
> This series does three things, all scoped to the Lenovo N22 DMI
> match:
> 
> 1. Disable the aggressive runtime PM/card-detect wake path for the
>    Braswell PCI SD controller.
> 2. Bypass the broken firmware card-detect GPIO path and use polling
>    for card insertion detection.
> 3. Prevent the competing ACPI INT33BB:00 node from binding on this
>    machine so the PCI SDHCI driver can own the controller.

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?

In patch 3, you say the SDHCI APCI driver repeatedly defers.  Is that
because it is waiting for the GPIO driver for the Card Detect GPIO?

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?


> 
> With these changes applied, the SD slot binds through sdhci-pci and
> detects and mounts SD cards again on the Lenovo N22.
> 
> Tested on:
>   Lenovo N22 Model 80S6 / MTM 80S60001US
>   Intel Celeron N3050 (Braswell)
>   Debian 13
>   Linux 6.19.6
> 
> Nelson Johnson (3):
>   mmc: sdhci-pci: disable aggressive runtime PM for Braswell SD on
>     Lenovo N22
>   mmc: sdhci-pci: force polling card detect for Braswell SD on Lenovo
>     N22
>   mmc: sdhci-acpi: exclude INT33BB:00 from ACPI binding on Lenovo N22
> 
>  drivers/mmc/host/sdhci-acpi.c     | 10 ++++++++++
>  drivers/mmc/host/sdhci-pci-core.c | 33 ++++++++++++++++++++++++++-----
>  2 files changed, 38 insertions(+), 5 deletions(-)
> 

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

[Nelson Johnson]

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

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

[Andy Shevchenko]

+Cc: Hans

On Fri, Mar 20, 2026 at 11:47:53AM -0500, 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
>   - 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
> 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
> 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.
> 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.

I believe Adrian added me to the Cc list to hear my opinion as I heard
about Bay Trail and similar machines more often than him nowadays. Yet
I am not working directly with them much, Hans does (or at least recently
did a lot). Nevertheless, looking briefly into the series and this message
I kinda tend to agree to make patches go in. We have tons of Bay Trail
machines from recent years and they are still supported well enough by
vanilla kernel (thanks to Hans).

TL;DR: I can look a bit closer and review the patches.

P.S.
I have installed a home router last year based on Bay Trail :-)


-- 
With Best Regards,
Andy Shevchenko

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

[Andy Shevchenko]

On Fri, Mar 20, 2026 at 06:55:04PM +0100, Andy Shevchenko wrote:
> On Fri, Mar 20, 2026 at 11:47:53AM -0500, Nelson Johnson wrote:
> > On Fri, Mar 20, 2026 at 8:27 AM Adrian Hunter wrote:

...

> I kinda tend to agree to make patches go in. We have tons of Bay Trail

(Same applicable to Braswell and Cherry Trail (Cherry View) devices.)

> machines from recent years and they are still supported well enough by
> vanilla kernel (thanks to Hans).
> 
> TL;DR: I can look a bit closer and review the patches.

Okay, after looking closer at them I think it feels like a hack approach
(or one that is done in a wrong place). If you read my comment on patch 3
the ACPI enumeration and PM domain is handled there. When device is present
in both PCI and ACPI in accordance with ACPI specification, if I am not
mistaken, it should extend the existing PCI capabilities. I.o.w. if any
contradictions with PCI resources or so the PCI should be taken as correct
ones.

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

-- 
With Best Regards,
Andy Shevchenko

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.

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

[Hans de Goede]

Hi,

On 21-Mar-26 00:07, Nelson Johnson wrote:
> 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.

Thank you. Note it might still be useful to share the full output
of acpidump.

So the above indeed describes the SD-slot MMC controller in
ACPI mode. WhenAndy wrote: "When device is present in both PCI and
ACPI in accordance with ACPI specification, if I am not
mistaken, it should extend the existing PCI capabilities."

I believe Andy was talking about your typical PCI[-e] slot ACPI
companion fwnode / device, which adds some extra info about
the slot.

But in this case it indeed seems the whole SD-slot controller
is simply described in both ACPI and enumerated through PCI
which is rather broken. And it being marked as a SDIO slot
is also broken, so I think your ACPI tables are just quite
broken.

Still I wonder if you've looked into BIOS settings to fix this ?

Some Cherry Trail devices have a BIOS option to switch
the BIOS from a Windows compatible mode to an Android compatible
mode.  I've worked more with Cherry Ttail then with Braswell,
so I'm not sure if the same also applies to Braswell but this
might be worth a shot.

Can you try dd-ing a Fedora Workstation Live iso to an USB
stick and then hit the BIOS bootmenu key (F12?) and boot
from that? If this is indeed one of these double identity
BIOS-es it will see Fedora's shim is signed with microsoft's
key and switch to Windows mode. If it does this it will immediately
reboot into the new mode, so need to hit F12 a second time
and select the USB stick a second time.

And then under Fedora check if the sd slot is still seen
twice.

> 
> lspci -vv -n -s 0000:00:12.0 on vanilla kernel:
> 
>     00:12.0 0805: 8086:2296 (rev 21) (prog-if 01)

Ok, so at least on the PCI side this does have the SD slot
device-id and not the sdio-slot one.


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

If you look at drivers/mmc/host/sdhci-acpi.c you'll see an existing
sdhci_acpi_quirks[] mechanism with DMI quirks there. I wonder what
happens if you GPIO card detection there by adding a new
DMI_QUIRK_SDIO_IS_SD quirk for your model there and when that is set
use sdhci_acpi_slot_int_sd instead of sdhci_acpi_slot_int_sdio +
disable any use of GPIO for card-detect ?

I'm hoping that using the ACPI path will avoid the need for

"[PATCH 1/3] mmc: sdhci-pci: disable aggressive runtime PM for Braswell SD on Lenovo N22"

and we can use the same quirk to fix sdio -> sd to also force
polling.

I hope the PCI driver will then simply fail to probe due to
a resource conflict ...

Alternative if we do go the route of this v1 patchset you may want
to use the override_status_id mechanism in:

drivers/acpi/x86/utils.c

Adding a NOT_PRESENT_ENTRY_PATH match on the INT33BB device
to ignore it.

Hmm, I see that mmc1 is enumerated as 80860F14:00 I wonder
if there is a 80860F14:01 with a status of 0 and if we really
need to use that one instead of the INT33BB one.

Normally a single laptop/tablet uses either all PCI or
all ACPI enumeration for the MMC controllers and if using
ACPI it tends to be consistent wrt which ACPI HIDs it uses ...

Again having a full acpidump to look at would be good.

Regards,

Hans

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.

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

[Andy Shevchenko]

+Cc: Hans on FYI basis, but your ideas, comments, et cetera are welcome!

On Mon, Mar 16, 2026 at 04:23:22PM -0500, Nelson Johnson wrote:
> This series fixes the long-broken SD slot on the Lenovo N22
> (Model 80S6 / MTM 80S60001US) with Intel Celeron N3050 Braswell
> hardware running Debian 13 and Linux 6.19.6.
> 
> The regression goes back to kernel 4.14. The Braswell SD controller
> (PCI ID 8086:2296) is exposed by firmware through both PCI
> 0000:00:12.0 and ACPI INT33BB:00 at \_SB_.PCI0.SDHB.
> 
> On this machine the newer runtime PM and card-detect handling no
> longer works reliably, and the ACPI path permanently defers because
> its dependency never becomes available. That leaves the slot unusable
> unless the controller is forced back onto the working PCI path with
> machine-specific quirks.
> 
> This series does three things, all scoped to the Lenovo N22 DMI
> match:
> 
> 1. Disable the aggressive runtime PM/card-detect wake path for the
>    Braswell PCI SD controller.
> 2. Bypass the broken firmware card-detect GPIO path and use polling
>    for card insertion detection.
> 3. Prevent the competing ACPI INT33BB:00 node from binding on this
>    machine so the PCI SDHCI driver can own the controller.
> 
> With these changes applied, the SD slot binds through sdhci-pci and
> detects and mounts SD cards again on the Lenovo N22.

> Tested on:
>   Lenovo N22 Model 80S6 / MTM 80S60001US
>   Intel Celeron N3050 (Braswell)
>   Debian 13
>   Linux 6.19.6

-- 
With Best Regards,
Andy Shevchenko

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

[Nelson Johnson]

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?

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

[Hans de Goede]

Hi,

On 21-Mar-26 16:25, Nelson Johnson wrote:
> 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

Ok, interesting so the 80860F14:01 gets seen as a companion
to the 0000:00:12.0 PCI slot/function. Even though it looks
like 80860F14:01 should simply be a standalone ACPI
enumerated SD card controller and 0000:00:12.0 should not
be visible on the PCI bus at all.

Note both PCI 0000:00:12.0 and 80860F14:01 point to
the same hw, but typically only one of the ways of seeing
the hw is enabled for the OS. Well I guess that is the
case here since 80860F14:01 reports _STA = 0.


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

Right but the 80860F14:01 dev being disabled seems correct, since
it should only be enabled when PCI enumeration for  0000:00:12.0
is disabled.

Given that it is weird it has an _ADR ACIP field at all, since
it is not a PCI companion, it is another way to enumerate
the same hw when PCI enumeration for that "ip block" is
disabled.

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

Ok, thank you for trying.

Have you looked for a BIOS update from Lenovo ? Also have you tried
to do "load setup defaults" or something similar in the BIOS ?

It is possible that the layout of (hidden) BIOS parameters has
changed between BIOS versions and the updater was not smart
enough to wipe the nvram. Then you're using a set of hidden BIOS
parameters meant for an older version which can wreck havoc.

Given how funky this all is, looking for a BIOS update +
doing load-setu-defaults + save in the BIOS would be one
of the first things I would try.

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

I think that the whole INT33BB:00 device is a red-herring and
can simply be ignored. It uses SI0A as base address, where as
80860F14:00 uses SD0A as base address.

These Braswell chips have 3 SD/MMC controllers:

1. The eMMC controller, this seems to be ACPI [80860F14:00] on your hw
2. A SDIO controller for SDIO attached wifi, this seems to be
   ACPI [INT33BB:00] on your hw and is unused (Wifi attached over PCI?)
3. A SD card slot controller, this seems to be pci 0000:00:12.0 on
   your hw, that or ACPI [80860F14:01]. I suspect things might work
   better in ACPI [80860F14:01] enumeration mode, but that would require
   disabling the PCI enumeration otherwise things get even more funky ...

So I think the INT33BB:00 device describes the actual SDIO controller
and you don't need to disable it.

So the first thing to do would be to test your original patches without
the patch to disable the INT33BB probing in the sdhci-acpi code.

Once we've confirmed that that patch is not necessary we can look at
fixing the issues with the PCI enumerated sd-card slot controller.

And yes trying to override _STA for 80860F14:01 is an interesting
experiment, this will give the shdci-pci driver access to the sdcard
detect GPIO I believe. And also to some power-management functions,
so maybe that is enough to fix things.

Since Linux sees the 80860F14:01 as a PCI-companion it should not
instantiate a platform-device for it, so sdhci-acpi will not
try to use it.

But first do the bios-update (if available) + load-setup-defaults +
save thingie please.

Regards,

Hans

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

[Nelson Johnson]

On Sat, Mar 21, 2026 at 05:14:44PM +0100, Hans de Goede wrote:
> Have you looked for a BIOS update from Lenovo? Also have you tried
> to do "load setup defaults" or something similar in the BIOS?
>
> So the first thing to do would be to test your original patches
> without the patch to disable the INT33BB probing in the sdhci-acpi
> code.
>
> And yes trying to override _STA for 80860F14:01 is an interesting
> experiment.
>
> But first do the bios-update (if available) + load-setup-defaults +
> save thingie please.

Results of all three tests follow.

BIOS update check:

The N22 is running BIOS version 0YCN26WW dated 2019-03-11. This is
the latest version available from Lenovo for this model — no newer
version exists. fwupd confirms no System Firmware updates are
available. Load Setup Defaults was performed and all visible BIOS
settings were reset. ACPI device status was unchanged after reset:

    80860F14:00  status: 15
    80860F14:01  status:  0
    INT33BB:00   status: 15

Stale NVRAM does not appear to be the cause. This BIOS was present
during all previous testing reported in this thread.

Patches 1 and 2 without Patch 3:

Tested on a kernel built from the vanilla 6.19.6 base with only
Patches 1 and 2 applied. The SD slot works correctly without
Patch 3. sdhci-pci binds 0000:00:12.0, BusMaster is enabled, and
the 128GB SDXC card is detected at UHS-I SDR104. INT33BB:00 still
fails to initialize as a non-removable card but does not prevent
sdhci-pci from owning the controller. Patch 3 is not necessary
on this machine.

    [    3.055743] mmc0: SDHCI controller on ACPI [INT33BB:00] using ADMA
    [    3.063153] sdhci-pci 0000:00:12.0: SDHCI controller found [8086:2296] (rev 21)
    [    3.063881] mmc1: SDHCI controller on PCI [0000:00:12.0] using ADMA
    [    3.248057] mmc0: Failed to initialize a non-removable card
    [    4.007369] mmc1: new UHS-I speed SDR104 SDXC card at address aaaa
    [    4.179918] mmcblk1: mmc1:aaaa SD128 119 GiB

    Control: BusMaster+
    Kernel driver in use: sdhci-pci

override _STA for 80860F14:01 experiment:

Tested on a vanilla 6.19.6 kernel with a PRESENT_ENTRY_HID entry
added to the override_status_ids table in drivers/acpi/x86/utils.c:

    PRESENT_ENTRY_HID("80860F14", "3", INTEL_ATOM_AIRMONT, {
        DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
        DMI_MATCH(DMI_BOARD_NAME, "N22"),
    }),

The override did not change 80860F14:01 status. It remained at 0
after boot. sdhci-pci did not bind, BusMaster stayed off, and the
SD card was not detected. The broken behavior was identical to
vanilla. The override as implemented here did not take effect.

Given that Patches 1 and 2 alone restore full functionality, is
a two-patch v2 series the right next step, or is there something
further you would like to investigate first?

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

[Andy Shevchenko]

On Sat, Mar 21, 2026 at 10:25:01AM -0500, Nelson Johnson wrote:
> 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.

A side note: Your email lost the In-reply-to and possibly other headers, so it
looks like a new email thread, however by subject it seems as a reply into the
previous discussion. Check if you have nothing wrong with your email setup.

-- 
With Best Regards,
Andy Shevchenko

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

[Nelson Johnson]

On Mon, Mar 23, 2026 at 12:14:09PM +0200, Andy Shevchenko wrote:
> A side note: Your email lost the In-reply-to and possibly other
> headers, so it looks like a new email thread, however by subject
> it seems as a reply into the previous discussion. Check if you
> have nothing wrong with your email setup.

Apologies for the broken threading. It looks like my last reply
did not preserve the expected threading headers on-list. As a
first-time submitter I was not aware of the distinction between
on-list and off-list replies. I will reply to list-archived
messages going forward and double-check the generated headers
before sending.