Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus

From: Bjorn Helgaas <bhelgaas@google.com>
To: bharat.bhushan@nxp.com
Cc: "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	bharatb.yadav@gmail.com, David Daney <david.daney@cavium.com>,
	jglauber@cavium.com, mbroemme@libmpq.org,
	chrisrblake93@gmail.com
Subject: Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
Date: Wed, 28 Nov 2018 14:15:36 -0600	[thread overview]
Message-ID: <CAErSpo7By1t5X=M=x_+Fs8TeROACBnS3f5ujsi=Ewiogh=-wRg@mail.gmail.com> (raw)
In-Reply-To: <VI1PR04MB48457E23AA3354316C7782D69AD10@VI1PR04MB4845.eurprd04.prod.outlook.com>

On Tue, Nov 27, 2018 at 10:32 PM Bharat Bhushan <bharat.bhushan@nxp.com> wrote:

> > -----Original Message-----
> > From: Alex Williamson <alex.williamson@redhat.com>
> > Sent: Tuesday, November 27, 2018 9:39 PM
> > To: Bjorn Helgaas <helgaas@kernel.org>
> > Cc: Bharat Bhushan <bharat.bhushan@nxp.com>; linux-pci@vger.kernel.org;
> > linux-kernel@vger.kernel.org; bharatb.yadav@gmail.com; David Daney
> > <david.daney@cavium.com>; Jan Glauber <jglauber@cavium.com>; Maik
> > Broemme <mbroemme@libmpq.org>; Chris Blake
> > <chrisrblake93@gmail.com>
> > Subject: Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
> >
> > On Tue, 27 Nov 2018 09:33:56 -0600
> > Bjorn Helgaas <helgaas@kernel.org> 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.