linux-kernel - Re: [PATCH] PCI: pciehp: Do not turn off slot if presence comes up after link

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: <20190214070100.kvikmkkcrp2d32sm@wunner.de>
Date:   Thu, 14 Feb 2019 08:01:00 +0100
From:   Lukas Wunner <lukas@...ner.de>
To:     Alex_Gagniuc@...lteam.com
Cc:     mr.nuke.me@...il.com, bhelgaas@...gle.com, Austin.Bolen@...l.com,
        keith.busch@...el.com, Shyam.Iyer@...l.com, gustavo@...eddedor.com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: pciehp: Do not turn off slot if presence comes up
 after link

On Wed, Feb 13, 2019 at 06:55:46PM +0000, Alex_Gagniuc@...lteam.com wrote:
> On 2/13/19 2:36 AM, Lukas Wunner wrote:
> > > (*) A bit hypothetical: There is no hardware yet implementing the ECN.
> > 
> > Hm, this contradicts Austin Bolen's e-mail of Jan 25 that "Yes, this
> > platform disables in-band presence" (when asked whether your host
> > controller already adheres to the ECN).
> 
> Both statements are true. The hardware does indeed disable in-band 
> presence, in a rudimentary way that is not compliant with the ECN -- it 
> doesn't implement the bits required by the ECN.

Ugh, can a BIOS update make those machines compliant to the ECN
or do we need a quirk specifically for them?


> >  Polling PDS in
> > pcie_wait_for_link() or disabling either PDC or DLLSC if in-band presence
> > is disabled seems simpler to reason about.
> 
> pcie_wait_for_link() is generic PCIe layer. I don't think mixing hotplug 
> concepts is a good layering violation.

The function used to live in pciehp_hpc.c, but commits 9f5a70f18c58
and f0157160b359 moved it to generic code to allow code sharing with
the DPC driver.  That's the only reason it's in generic code AFAICS.


> >> in-band PD disable (what's a good acronym for that, BTW?)
> > 
> > I don't know, maybe inband_presence_disabled?
> 
> PCI_EXP_SLTCAP2_IBPD ?

Yes, something like that.  It should match the spec, which I have no
access to.

Thanks,

Lukas