On Tue, Nov 27, 2018 at 10:32 PM Bharat Bhushan <bharat.bhushan@xxxxxxx> wrote: > > -----Original Message----- > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Tuesday, November 27, 2018 9:39 PM > > To: Bjorn Helgaas <helgaas@xxxxxxxxxx> > > Cc: Bharat Bhushan <bharat.bhushan@xxxxxxx>; linux-pci@xxxxxxxxxxxxxxx; > > linux-kernel@xxxxxxxxxxxxxxx; bharatb.yadav@xxxxxxxxx; David Daney > > <david.daney@xxxxxxxxxx>; Jan Glauber <jglauber@xxxxxxxxxx>; Maik > > Broemme <mbroemme@xxxxxxxxxx>; Chris Blake > > <chrisrblake93@xxxxxxxxx> > > Subject: Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus > > > > On Tue, 27 Nov 2018 09:33:56 -0600 > > Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > > 4) Is there a hardware erratum for this? If so, please include the > > > URL here. > > No h/w errata as of now. Does that mean (a) the HW folks agree this is a hardware problem but they haven't written an erratum, (b) there is an erratum but it isn't public, (c) we don't have any concrete evidence of a hardware problem, but things just don't work if we do a bus reset, (d) something else? > In pci_reset_secondary_bus() I have tried to increase the delay after reset but not helped. > Do I need to add delay at some other place as well? No, I think the place you tried should be enough. You should also be able to exercise this from user-space by using "setpci" to set and clear the Secondary Bus Reset bit in the Bridge Control register. Then you can also use setpci to read/write config space of the NIC. The kernel would normally read the Vendor and Device IDs as the first access to the device during enumeration. You also might be able to learn something by using "lspci -vv" on the bridge before and after the reset to see if it logs any AER bits (if it supports AER) or the other standard error logging bits.
