On Thu, Feb 8, 2024 at 9:37 AM Daniel Drake <drake@xxxxxxxxxxxxx> wrote:
> > What would be the downside of skipping the DMI table and calling
> > pci_d3cold_disable() always? If this truly is a Root Port defect, it
> > should affect all platforms with this device, and what's the benefit
> > of relying on BIOS to use StorageD3Enable to avoid the defect?
>
> I had more assumed that it was a platform-specific DSDT bug, in that
> PEG0.PXP._OFF is doing something that PEG0.PXP._ON is unable to
> recover from, and that other platforms might handle the suspend/resume
> of this root port more correctly. Not sure if it is reasonable to
> assume that all other platforms on the same chipset have the same bug
> (if that's what this is).
Just realised my main workstation (Dell XPS) has the same chipset.
The Dell ACPI table has the exact same suspect-buggy function, which
the affected Asus system calls from PEG0.PXP._OFF:
Method (DL23, 0, Serialized)
{
L23E = One
Sleep (0x10)
Local0 = Zero
While (L23E)
{
If ((Local0 > 0x04))
{
Break
}
Sleep (0x10)
Local0++
}
SCB0 = One
}
(the "L23E = One" line is the one that writes a value to config offset
0xe2, if you comment out this line then everything works)
However, on the Dell XPS system, nothing calls DL23() i.e. it is dead code.
Comparing side by side:
Asus root port (PC00.PEG0) has the PXP power resource which gets
powered down during D3cold transition as it becomes unused. Dell root
port has no power resources (no _PR0).
Asus NVM device sitting under that root port (PC00.PEG0.PEGP) has
no-op _PS3 method, but Dell does not have _PS3. This means that Dell
doesn't attempt D3cold on NVMe nor the parent root port during suspend
(both go to D3hot only).
Let me know if you have any ideas for other useful comparative experiments.
Daniel
