On Fri, Aug 01, 2025 at 04:29:41PM GMT, Krishna Chaitanya Chundru wrote: > PCIe WAKE# interrupt is needed for bringing back PCIe device state from > D3cold to D0. > > This is pending from long time, there was two attempts done previously to > add WAKE# support[1], [2]. Those series tried to add support for legacy > interrupts along with WAKE#. Legacy interrupts are already available in > the latest kernel and we can ignore them. For the wake IRQ the series is > trying to use interrupts property define in the device tree. > > This series is using gpio property instead of interrupts, from > gpio desc driver will allocate the dedicate IRQ. > > According to the PCIe specification 6, sec 5.3.3.2, there are two defined > wakeup mechanisms: Beacon and WAKE# for the Link wakeup mechanisms to > provide a means of signaling the platform to re-establish power and > reference clocks to the components within its domain. Adding WAKE# > support in PCI framework. > > According to the PCIe specification, multiple WAKE# signals can exist in a > system. In configurations involving a PCIe switch, each downstream port > (DSP) of the switch may be connected to a separate WAKE# line, allowing > each endpoint to signal WAKE# independently. To support this, the WAKE# > should be described in the device tree node of the upstream bridge to which > the endpoint is connected. For example, in a switch-based topology, the > WAKE# GPIO can be defined in the DSP of the switch. In a direct connection > scenario, the WAKE# can be defined in the root port. If all endpoints share > a single WAKE# line, the GPIO should be defined in the root port. > I think you should stop saying 'endpoint' here and switch to 'slot' as that's the terminology the PCIe spec uses while defining WAKE#. > During endpoint probe, the driver searches for the WAKE# in its immediate > upstream bridge. If not found, it continues walking up the hierarchy until > it either finds a WAKE# or reaches the root port. Once found, the driver > registers the wake IRQ in shared mode, as the WAKE# may be shared among > multiple endpoints. > I don't think we should walk the hierarchy all the way up to RP. If the slot supports WAKE#, it should be defined in the immediate bridge node of the endpoint (as DT uses bridge node to described the slot). Otherwise, if the slot doesn't use WAKE#, walking up till RP may falsely assign wake IRQ to the endpoint. - Mani -- மணிவண்ணன் சதாசிவம்
