Thread (30 messages) 30 messages, 7 authors, 2017-08-31

Possible regression between 4.9 and 4.13

From: lukas@wunner.de (Lukas Wunner)
Date: 2017-08-30 06:36:23
Also in: linux-pci

On Tue, Aug 29, 2017 at 05:51:38PM +0200, Greg Kroah-Hartman wrote:
On Tue, Aug 29, 2017 at 05:34:56PM +0200, Lukas Wunner wrote:
quoted
On Tue, Aug 29, 2017 at 04:47:25PM +0200, Greg Kroah-Hartman wrote:
quoted
On Tue, Aug 29, 2017 at 03:38:52PM +0200, Lukas Wunner wrote:
Is 0xffffffff not a valid value to be stored in and read from mmio space?
For a specific register, doubtful
Well, "doubtful" means you don't know for sure.

It's fine to check for "all ones" as a heuristic if that's not a valid
value for the register read, however a hotplug notification is a
*definitive* indication the hardware is gone.

I you seem to prefer forgoing a *definitive* indication for a mere
heuristic, that doesn't make sense from my point of view.

It's a really long time for everything to shut down and to help
prevent the driver from going crazy, [...]
Also, there is always a race between when that notification has been
sent and processed on the PCIe channel and the reading of all 1s on the
PCI bus by the driver.
Yes I know that.  In practice the interrupt signaling hot removal
comes fast enough to prevent drivers from "going crazy", as I've
mentioned in this patch:

https://patchwork.kernel.org/patch/9405255/

For fun, try disconnecting a USB device from one of the more modern
laptops with a USB 3.1 connection on it.  The bios treats those as a pci
hotpluggable xhci controller on the PCI bus.  When the device is
disconnected, the BIOS rips out the PCI device as well, but all that
time, the xhci driver is thinking the device is still present as it
takes a while for the BIOS to do all of the needed housekeeping.
Yes, that is the case with Thunderbolt 3 controllers on non-Macs:
The XHCI controller appears below downstream bridge 2 of the Thunderbolt
controller's PCIe switch.  Once the last device is removed, the PCIe
switch and all devices below it disappear and the controller is powered
down.  The controller is thus only visible if powered up.  On Mac this
is all native instead:  Native pciehp, native tunnel setup, native PM.

quoted
quoted
quoted
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.
What about all of the non-pciehp platforms?  :)
Fair enough, those should be extended to set PCI_DEV_DISCONNECTED as well.

Thanks,

Lukas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help