Re: Possible regression between 4.9 and 4.13

[Lukas Wunner <lukas@wunner.de>]

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