linux-kernel - Re: [PATCH 3/3] PCI: pciehp: Add dmi table for in-band presence disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL5oW00xbnYk5=nT9v3rS4QTLShGfvzBgQLtsFh7xO2OyZqL3A@mail.gmail.com>
Date:   Tue, 1 Oct 2019 18:06:12 -0500
From:   Stuart Hayes <stuart.w.hayes@...il.com>
To:     "Alex G." <mr.nuke.me@...il.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Austin Bolen <austin_bolen@...l.com>, keith.busch@...el.com,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "Gustavo A . R . Silva" <gustavo@...eddedor.com>,
        Sinan Kaya <okaya@...nel.org>,
        Oza Pawandeep <poza@...eaurora.org>, linux-pci@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        lukas@...ner.de
Subject: Re: [PATCH 3/3] PCI: pciehp: Add dmi table for in-band presence disabled

On Tue, Oct 1, 2019 at 4:36 PM Alex G. <mr.nuke.me@...il.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@...il.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.