PCI: hotplug: Drop checking of PCI_BRIDGE_CONTROL in *_unconfigure_device()
authorMika Westerberg <mika.westerberg@linux.intel.com>
Thu, 9 Nov 2017 11:15:08 +0000 (14:15 +0300)
committerBjorn Helgaas <bhelgaas@google.com>
Tue, 19 Dec 2017 05:05:18 +0000 (23:05 -0600)
commit0f4bd8014db515999493baaa75d506cc8026c462
treec47e9175d0473b923eb495b8e0106e7f1141ebb0
parent1291a0d5049dbc06baaaf66a9ff3f53db493b19b
PCI: hotplug: Drop checking of PCI_BRIDGE_CONTROL in *_unconfigure_device()

When removing a bridge, pciehp_unconfigure_device() reads the
PCI_BRIDGE_CONTROL byte.  If this is a surprise hot-unplug, the device is
already gone and the read returns ~0, which pciehp_unconfigure_device()
interprets as having PCI_BRIDGE_CTL_VGA set.  This results in failure of
the remove operation:

  pciehp 0000:00:1c.0:pcie004: Slot(0): Link Down
  pciehp 0000:00:1c.0:pcie004: Slot(0): Card present
  pciehp 0000:00:1c.0:pcie004: Cannot remove display device 0000:01:00.0

Because of this the hierarchy is left untouched preventing further hotplug
operations.

Now, it is not clear why the check is there in the first place and why we
would like to prevent removing a bridge if it has PCI_BRIDGE_CTL_VGA set.
In case of PCIe surprise hot-unplug, it would not even be possible to
prevent the removal.

Given this and the issue described above, I think it makes sense to drop
the whole PCI_BRIDGE_CONTROL check from pciehp_unconfigure_device().  While
there do the same for shpchp_configure_device() based on the same reasoning
and the fact that the same bug might trigger in standard PCI hotplug as
well.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
drivers/pci/hotplug/pciehp_pci.c
drivers/pci/hotplug/shpchp_pci.c