On Wed, Feb 13, 2019 at 06:55:46PM +0000, Alex_Gagniuc@xxxxxxxxxxxx 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
