linux-kernel - Re: [PATCH v3 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]

Date:   Mon, 21 Oct 2019 19:13:32 -0500
From:   "Alex G." <mr.nuke.me@...il.com>
To:     Stuart Hayes <stuart.w.hayes@...il.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.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>,
        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@...r.kernel.org, lukas@...ner.de
Subject: Re: [PATCH v3 3/3] PCI: pciehp: Add dmi table for in-band presence
 disabled

On 10/21/19 1:19 PM, Stuart Hayes wrote:
> 
> 
> On 10/21/19 8:47 AM, Mika Westerberg wrote:
>> On Thu, Oct 17, 2019 at 03:32:56PM -0400, 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 02eb811a014f..4d377a2a62ce 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_OEM_STRING, "Dell System"),
>>
>> Sorry if this has been discussed previously already but isn't this going
>> to apply on all Dell systems, not just the affected ones? Is this the
>> intention?
>>
> 
> Yes, that is the intention. Applying this just makes the hotplug code wait for
> the presence detect bit to be set before proceeding, which ideally wouldn't hurt
> anything--for devices that don't have inband presence detect disabled, presence
> detect should already be up when the code in patch 2/3 starts to wait for it.
> 
> The only issue should be with broken hotplug implementations that don't ever
> bring presence detect active (these apparently exist)--but even those would still
> work, they would just take an extra second to come up.
> 
> On the other hand, a number of Dell systems have (and will have) NVMe
> implementations that have inband presence detect disabled (but they won't have
> the new bit implemented to report that), and they don't work correctly without
> this.

I think it's clearer if this is explained in a comment. That it doesn't 
break anything, and we're okay this applies to all hotplug ports, even 
those that are not in front of an NVMe backplane.

Alex