| Message ID | 20191001211419.11245-4-stuart.w.hayes@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | PCI: pciehp: Do not turn off slot if presence comes up after link | expand |
On 10/1/19 4:14 PM, Stuart Hayes wrote: > Some systems have in-band presence detection disabled for hot-plug PCI slots, > but do not report this in the slot capabilities 2 (SLTCAP2) register. On > these systems, presence detect can become active well after the link is > reported to be active, which can cause the slots to be disabled after a > device is connected. > > Add a dmi table to flag these systems as having in-band presence disabled. > > Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> > --- > drivers/pci/hotplug/pciehp_hpc.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c > index 1282641c6458..1dd01e752587 100644 > --- a/drivers/pci/hotplug/pciehp_hpc.c > +++ b/drivers/pci/hotplug/pciehp_hpc.c > @@ -14,6 +14,7 @@ > > #define dev_fmt(fmt) "pciehp: " fmt > > +#include <linux/dmi.h> > #include <linux/kernel.h> > #include <linux/types.h> > #include <linux/jiffies.h> > @@ -26,6 +27,16 @@ > #include "../pci.h" > #include "pciehp.h" > > +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = { > + { > + .ident = "Dell System", > + .matches = { > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"), > + }, > + }, > + {} > +}; > + I'm not sure that all Dell systems that were ever made or will be made have in-band presence disabled on all their hotplug slots. This was a problem with the NVMe hot-swap bays on 14G servers. I can't guarantee that any other slot or machine will need this workaround. The best way I found to implement this is to check for the PCI-ID of the switches behind the port. Alex
On Tue, Oct 1, 2019 at 4:36 PM Alex G. <mr.nuke.me@gmail.com> wrote: > > > > On 10/1/19 4:14 PM, Stuart Hayes wrote: > > Some systems have in-band presence detection disabled for hot-plug PCI slots, > > but do not report this in the slot capabilities 2 (SLTCAP2) register. On > > these systems, presence detect can become active well after the link is > > reported to be active, which can cause the slots to be disabled after a > > device is connected. > > > > Add a dmi table to flag these systems as having in-band presence disabled. > > > > Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> > > --- > > drivers/pci/hotplug/pciehp_hpc.c | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c > > index 1282641c6458..1dd01e752587 100644 > > --- a/drivers/pci/hotplug/pciehp_hpc.c > > +++ b/drivers/pci/hotplug/pciehp_hpc.c > > @@ -14,6 +14,7 @@ > > > > #define dev_fmt(fmt) "pciehp: " fmt > > > > +#include <linux/dmi.h> > > #include <linux/kernel.h> > > #include <linux/types.h> > > #include <linux/jiffies.h> > > @@ -26,6 +27,16 @@ > > #include "../pci.h" > > #include "pciehp.h" > > > > +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = { > > + { > > + .ident = "Dell System", > > + .matches = { > > + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"), > > + }, > > + }, > > + {} > > +}; > > + > > I'm not sure that all Dell systems that were ever made or will be made > have in-band presence disabled on all their hotplug slots. > > This was a problem with the NVMe hot-swap bays on 14G servers. I can't > guarantee that any other slot or machine will need this workaround. The > best way I found to implement this is to check for the PCI-ID of the > switches behind the port. > > Alex That is definitely true, not all Dell systems actually disable in-band presence detect and need this. However, we have a number of systems that need this, and we don't have the PCI IDs for all of these yet, so we decided it was preferable to just make all Dell systems wait for presence detect to go active. Since all of our systems support presence detect (either in-band or out-of-band), it shouldn't have any negative effects--on systems that support in-band presence, it will already be active and it won't spend any extra time waiting for it. If someone plugs in a device that has hot-plug slots with no support for presence detect at all (even though Dell doesn't support any), it should still work--it'll just take an extra second for them to come up.
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 1282641c6458..1dd01e752587 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -14,6 +14,7 @@ #define dev_fmt(fmt) "pciehp: " fmt +#include <linux/dmi.h> #include <linux/kernel.h> #include <linux/types.h> #include <linux/jiffies.h> @@ -26,6 +27,16 @@ #include "../pci.h" #include "pciehp.h" +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = { + { + .ident = "Dell System", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"), + }, + }, + {} +}; + static inline struct pci_dev *ctrl_dev(struct controller *ctrl) { return ctrl->pcie->port; @@ -898,6 +909,9 @@ struct controller *pcie_init(struct pcie_device *dev) ctrl->inband_presence_disabled = 1; } + if (dmi_first_match(inband_presence_disabled_dmi_table)) + ctrl->inband_presence_disabled = 1; + /* * If empty slot's power status is on, turn power off. The IRQ isn't * requested yet, so avoid triggering a notification with this command.
Some systems have in-band presence detection disabled for hot-plug PCI slots, but do not report this in the slot capabilities 2 (SLTCAP2) register. On these systems, presence detect can become active well after the link is reported to be active, which can cause the slots to be disabled after a device is connected. Add a dmi table to flag these systems as having in-band presence disabled. Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> --- drivers/pci/hotplug/pciehp_hpc.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)