]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit8242f4681b8ea218b4cef30ee5b0b980f908b8c5
treec47e9175d0473b923eb495b8e0106e7f1141ebb0
parentf46f7a864ffeb8668eeb7ce6a8595148d52edaeb
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