mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ben Chuang <ben.chuang@genesyslogic.com.tw>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Kyle Baedke" <kylebaedke@protonmail.com>,
	"VictorShih[施勝文]" <victor.shih@genesyslogic.com.tw>
Subject: Re: [BUG] Genesys GL9750 (17a0:9750) does not respond after its PCIe slot is powered back on from D3cold, on s2idle resume and at runtime (ASUS Vivobook 14 Flip TP3407SA, kernel 7.3.1)
Date: Thu, 5 Nov 2026 08:04:24 +0200	[thread overview]
Message-ID: <c6080d32-49d0-413b-8c37-74709dadd6f6@intel.com> (raw)
In-Reply-To: <vqOfI4cXijz1Ft480-_mX3XkrTT_-oQ78Xy6CPrXD_r5R06i7H03y3szJFA7JAVs9YsW93_hUQ0hz5bTYItb7RUml3cGwxPmW9gPFIcNY-8=@protonmail.com>

+ Ben Chuang

On 05/11/2026 05:32, Kyle Baedke wrote:
> 
> 
> On Wednesday, November 4th, 2026 at 2:52 PM, Kyle Baedke <kylebaedke@protonmail.com> wrote:
> First copy was in html mode this should be in plaintext
>> The GL9750 SD host controller in my laptop is dead after its PCIe slot has
>> been powered off and back on through the root port's ACPI power resource.
>> This happens on resume from s2idle, and I can also reproduce it at runtime
>> with no sleep involved. In both cases the link below the root port never
>> comes up, so the device reads as all-ones. The sdhci errors are a
>> consequence of that. I'm writing to the sdhci maintainers because the
>> device is driven by sdhci-pci-gli, but the failure occurs before the
>> driver can talk to the device.
>>
>> == System ==
>>
>>   Laptop:    ASUS Vivobook 14 Flip TP3407SA
>>   BIOS:      TP3407SA.308, 03/05/2026 (the latest available)
>>   Kernel:    7.3.1 (NixOS 26.11), x86_64
>>   Device:    0000:2c:00.0  Genesys Logic GL9750 [17a0:9750] rev 1,
>>              subsystem 1043:202f
>>   Upstream:  root port 0000:00:1c.4 (ACPI \_SB.PC00.RP05), link 2.5GT/s x1
>>   Cmdline:   intel_iommu=on iommu=pt pcie_aspm.policy=powersave
>>              (the relevant parameters)
>>   Sleep:     /sys/power/mem_sleep = [s2idle] deep. Selecting "deep" (S3)
>>              hangs the machine and needs power to be cut to recover, so
>>              s2idle is the only usable sleep mode.
>>
>> The root port's ACPI node has power resources (power_resources_D0 and
>> power_resources_D3hot in sysfs). The endpoint's ACPI node has none.
>>
>> Other firmware/kernel messages seen at boot:
>>
>>   ACPI: \_SB_.PEPD: Duplicate LPS0 _DSM functions (mask: 0x1)
>>   pci 0000:00:1c.4: mask Replay Timer Timeout Correctable Errors due to
>>       0000:2c:00.0 hardware defect
>>
>> == Symptom ==
>>
>> After the slot is powered back on, config space reads of the device return
>> ffff, the port's Link Status stays 0x1011 (Data Link Layer Link Active = 0,
>> not training), and sdhci reports:
>>
>>   mmc0: sdhci: Version: 0x0000ffff   (register dump is all 0xff)
>>   mmc0: enable PCI MSI failed, error=-22
>>   mmc0: Reset 0x1 never completed.
>>   mmc0: 3.3V regulator output did not become stable
>>   mmc0: Controller never released inhibit bit(s).
>>
>> On a healthy boot the port's Link Status is 0x3011.
>>
>> == Resume trace ==
>>
>> Captured with rtcwake -m mem -s 15 (s2idle), pm_debug_messages=1 and
>> dynamic debug enabled for drivers/pci/*, drivers/acpi/power.c and
>> drivers/acpi/device_pm.c:
>>
>>   [  145.370215] sdhci-pci 0000:2c:00.0: PCI PM: Suspend power state: D3hot
>>   [  145.406917] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned off
>>   [  145.406948] pcieport 0000:00:1c.4: PCI PM: Suspend power state: D3cold
>>   ...
>>   [  159.865842] ACPI: \_SB_.PC00.RP05: PM: Power state change: D3cold -> D0
>>   [  160.263869] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned on
>>   [  160.264234] ACPI: \_SB_.PC00.RP05: PM: Power state changed to D0
>>   [  160.264241] pcieport 0000:00:1c.4: power state changed by ACPI to D0
>>   [  160.276459] pcieport 0000:00:1c.4: ready 0ms after power up D3hot->D0uninitialized
>>   [  160.276866] pcieport 0000:00:1c.4: waiting 100 ms for downstream link, after activation
>>   [  161.297053] pcieport 0000:00:1c.4: Data Link Layer Link Active not set in 100 msec
>>   [  161.303943] sdhci-pci 0000:2c:00.0: restore config 0x3c: 0xffffffff -> 0x000001ff
>>   [  161.321478] mmc0: enable PCI MSI failed, error=-22
>>   [  161.421611] mmc0: Reset 0x1 never completed.
>>   [  161.741170] mmc0: 3.3V regulator output did not become stable
>>
>> The slot was off for about 15 s (145.407 to 160.264), so this is not a
>> short-off-time problem.
>>
>> == Reproduction without suspend ==
>>
>> From a healthy boot (device alive, no SD card inserted):
>>
>>   echo 1    > /sys/bus/pci/devices/0000:2c:00.0/remove
>>   echo 1    > /sys/bus/pci/devices/0000:00:1c.4/d3cold_allowed
>>   echo auto > /sys/bus/pci/devices/0000:00:1c.4/power/control
>>   # the root port's power_state reached D3cold after about 2 s
>>   sleep 1
>>   echo on   > /sys/bus/pci/devices/0000:00:1c.4/power/control
>>   # port is D0 again, but its Link Status is 0x1011 (DLActive = 0)
>>   echo 1    > /sys/bus/pci/rescan     # repeated once per second for 15 s
>>
>> The device never reappears, and Link Status stays 0x1011 for the whole
>> 15 s. This uses only a 1 s off time.
>>
>> == What I tried ==
>>
>> Suspend variants, each run with rtcwake -m mem -s 15 (s2idle), no SD card
>> inserted. All of these failed on the first cycle:
>>
>>   - no changes
>>   - endpoint power/control=on
>>   - root port power/control=on
>>   - endpoint link/l1_2_aspm and link/l1_2_pcipm set to 0
>>   - endpoint link/l1_aspm, l1_1_aspm, l1_2_aspm, l1_1_pcipm, l1_2_pcipm
>>     all set to 0
>>   - endpoint removed before suspend, rescanned after resume
>>
>> This one passed 10/10 cycles (device alive 2 s and 8 s after resume, port
>> Link Status 0x3011 each time):
>>
>>   - d3cold_allowed=0 on both the endpoint and the root port, set just
>>     before suspend and restored to 1 right after resume
>>
>> Recovery attempted after a failed resume, with the root port held in D0
>> (power/control=on) and the rescan polled for 15 s per stage. None brought
>> the device back, and Link Status stayed 0x1011 throughout:
>>
>>   - remove + rescan
>>   - secondary bus reset on the root port, then rescan
>>   - Link Disable / enable on the root port, then rescan
>>
>> == Questions ==
>>
>> 1. Is this a known issue with this device or this platform's slot power-on
>>    method?
>> 2. What additional tracing would help (ACPI AML debugging, GPIO/pinctrl
>>    state before and after the power resource turns on, anything else)?
>>
>> I can build and test patches on this machine.
>>
>> Thanks,
>> Kyle
>>
>> Sent with Proton Mail secure email.


      reply	other threads:[~2026-11-05  6:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <x4G_0cgWnHWJtmgP4iX3hFfwwbWDyVuO9Ps8Pv_Rnq4VguufBRLzZex1IxGuTtaYfU7tS7U8RbKjB2I54HxfEmPk3gzKWvYDAyuZXrtWbDU=@protonmail.com>
2026-11-05  3:32 ` Kyle Baedke
2026-11-05  6:04   ` Adrian Hunter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6080d32-49d0-413b-8c37-74709dadd6f6@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=ben.chuang@genesyslogic.com.tw \
    --cc=bhelgaas@google.com \
    --cc=kylebaedke@protonmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=victor.shih@genesyslogic.com.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®