Re: [PATCH RFC] PCI/PME: fix PME runtime PM handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Heiner,

On Sun, Dec 30, 2018 at 12:06:14PM +0100, Heiner Kallweit wrote:
> I face the issue that no PME is generated if the network cable is
> re-plugged. To explain that in a little more detail:
> r8169 driver enters runtime suspend 10 seconds after cable is detached.
> LinkUp detection is armed and device enters D3hot. When the cable is
> re-plugged Linkup should generate a PME and device is resumed.
> But system receives no PME from the device.
> 
> Wake-on-LAN from S3 works perfectly fine and generates a PME.
> 
> After checking the pcie pme code and some experiments I found that
> the following fixes the issue for me. Now system receives the PME
> and properly runtime-resumes the network device.
> 
> But I'm no expert in PCIe and PME, therefore I'm not sure whether
> the fix is correct. Please advise.
>
> Adding also Mika as author of 0e157e528604 ("PCI/PME: Implement
> runtime PM callbacks").

The root port cannot trigger an interrupt when it is in D3 (hot or cold)
so there needs to be a way to "wakeup" the hierarchy first which is
typically done by using sideband signal called WAKE#. Once the hierarchy
is brought back to communicating state the PME message is propagated to
the root port and the interrupt triggers (now the root port is in D0).
For some reason this does not seem to happen in your case and to
understand why we would need to gather a bit more information.

Can you file a kernel bug about this on bugzilla.kernel.org? Then attach
there acpidump and output of 'sudo lspci -vv'.

Thanks!



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux