linux-kernel - Re: [PATCHv4 2/2] PCI: fu740: Force gen1 for initial device probe

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: <alpine.DEB.2.21.2202232100220.27002@angie.orcam.me.uk>
Date:   Wed, 23 Feb 2022 21:19:47 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Bjorn Helgaas <helgaas@...nel.org>
cc:     Ben Dooks <ben.dooks@...ethink.co.uk>, paul.walmsley@...ive.com,
        greentime.hu@...ive.com, lorenzo.pieralisi@....com,
        robh@...nel.org, kw@...ux.com, bhelgaas@...gle.com,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-riscv@...ts.infradead.org
Subject: Re: [PATCHv4 2/2] PCI: fu740: Force gen1 for initial device probe

On Wed, 23 Feb 2022, Bjorn Helgaas wrote:

> > +	dw_pcie_dbi_ro_wr_dis(dw);
> > +}
> > +
> >  static int fu740_pcie_start_link(struct dw_pcie *pci)
> >  {
> >  	struct device *dev = pci->dev;
> >  	struct fu740_pcie *afp = dev_get_drvdata(dev);
> >  
> > +	/* Force PCIe gen1 otherwise Unmatched board does not probe */
> > +	fu740_pcie_force_gen1(pci, afp);
> 
> I guess the "Unmatched" board is the only thing we need to care about
> here?  Are there or will there be other boards that don't need this?

 I wonder if this is the other side of a supposed erratum observed here:

<https://lore.kernel.org/all/alpine.DEB.2.21.2202010240190.58572@angie.orcam.me.uk/>

Downstream there's the same ASMedia ASM2824 PCIe switch whose downstream 
ports don't want to train with a Pericom part above Gen1.

 Of course we don't know an ASM2824 is there until we have successfully 
negotiated the link, so we may have to generalise my proposal if we can 
find a way similar to what I have done for U-boot that does not disturb 
Linux's operation.  This is because there are PCIe option cards out there 
with the ASM2824 onboard, so it could be possible for the problem to 
trigger anywhere where the conditions for the erratum are met.

 Also in that case retraining should work with the cap removed to get a 
higher final speed just as with the Pericom part.

  Maciej