On Tue, Aug 29, 2017 at 04:47:25PM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 29, 2017 at 03:38:52PM +0200, Lukas Wunner wrote: > > On Tue, Aug 29, 2017 at 04:28:53PM +0300, Mathias Nyman wrote: > > > Then again it might be a bit too drastic to kill xhci just because > > > we read 0xffffffff once from a mmio xhci register. Maybe we should > > > return an error a couple times before actually tearing down xhci. > > > > > > This tight check was originally done to detect pci hotplug removed > > > hosts as soon as possible. > > > > Just make pci_dev_is_disconnected() public to detect PCI hot removal. > > We *know* when the device was hot removed, so I think there's no need > > to guess that based on reading "all ones" from mmio (which may happen > > for entirely legitimate reasons unrelated to hot removal). > > No, you don't always "know" when a device is removed, don't rely on it, > not all platforms support that. Please explain, which platforms don't support that? They wouldn't be compliant with the spec it seems. PCIe r3.1, section 6.7.3: "A Downstream Port with hot-plug capabilities supports the following hot-plug events: Presence Detect Changed A Downstream Port with hot-plug capabilities monitors the slot it controls for the slot events listed above. [...] If enabled through the associated enable field, slot events must generate a software notification." And pciehp sets the flag on all downstream devices that they're removed once the software notification has been received and processed. > Reading all ff shows the device is removed, that's all the PCI spec > guarantees. What other legitimate reason could that happen for? Is 0xffffffff not a valid value to be stored in and read from mmio space? Best regards, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
