[lkml]   [2018]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
On Tue, Nov 27, 2018 at 10:32 PM Bharat Bhushan <> wrote:

> > -----Original Message-----
> > From: Alex Williamson <>
> > Sent: Tuesday, November 27, 2018 9:39 PM
> > To: Bjorn Helgaas <>
> > Cc: Bharat Bhushan <>;;
> >;; David Daney
> > <>; Jan Glauber <>; Maik
> > Broemme <>; Chris Blake
> > <>
> > Subject: Re: [PATCH] PCI: Mark NXP LS1088 to avoid bus reset bus
> >
> > On Tue, 27 Nov 2018 09:33:56 -0600
> > Bjorn Helgaas <> 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.

 \ /
  Last update: 2018-11-28 21:17    [W:0.094 / U:4.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site