Just to add more colour: If a switch is removed from the RP. All non posted's will time out. This includes a config read of any switch P2P. I believe Keith is saying if a read comes down to read the DPC status on a Switch DS P2P that read will time out after the host TMO. Once that occurs, the IIO will generate all 1s back to the DPC driver. It means all the back end drivers (DPC, AER, Hot Plug, NVMe) need to have some understanding that all 1s means "something happened". In the case of the DPC driver, we know the DPC status should never have 1s in the most significant bits so returning all 1s is a special return type that needs to be handled. Wes -----Original Message----- From: Wesley Yung Sent: Wednesday, May 10, 2017 9:43 AM To: 'Keith Busch' <keith.busch@xxxxxxxxx>; Wei Zhang <wzhang@xxxxxx> Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>; linux-pci@xxxxxxxxxxxxxxx; Sammy Hui <sammy.hui@xxxxxxxxx>; Joseph Gruher <joseph.r.gruher@xxxxxxxxx>; Krishna Dhulipala <krishnad@xxxxxx> Subject: RE: [PATCH 1/2] pcie/dpc: Skip DPC event if device is not present Hey Keith, Does the RC Downstream ports also have DPC capability so the driver actually loads for the Root Port DSPs? Just trying to understand the mechanism. For Wei's specific use case, removing a switch from the RP is not officially supported but technically it should be possible to do so. On the switch end we just need to know where the ecosystem is at so we can make sure to play nice. Wes -----Original Message----- From: Keith Busch [mailto:keith.busch@xxxxxxxxx] Sent: Wednesday, May 10, 2017 9:45 AM To: Wei Zhang <wzhang@xxxxxx> Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>; linux-pci@xxxxxxxxxxxxxxx; Wesley Yung <wesley.yung@xxxxxxxxxxxxx>; Sammy Hui <sammy.hui@xxxxxxxxx>; Joseph Gruher <joseph.r.gruher@xxxxxxxxx>; Krishna Dhulipala <krishnad@xxxxxx> Subject: Re: [PATCH 1/2] pcie/dpc: Skip DPC event if device is not present EXTERNAL EMAIL On Wed, May 10, 2017 at 04:35:06PM +0000, Wei Zhang wrote: > Hi Keith, > > I see. I thought the current CPU root complex does not support such a use case, ie removing the DPC switch device itself and might result in kernel panic. But I agree this will make the code future-proof when CPU does support such a case in the future. What do you mean in the future? I do this today (hotplug enclosures), but I need this fix in place otherwise we get a use-after-free when the DPC work queue runs after the hotplug code freed the topology that includes the DPC parts.
