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

+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

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(-)
>

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.

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.

+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

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

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.

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