From: Bjorn Helgaas <helgaas@kernel.org>
To: Jordan Hargrave <Jordan_Hargrave@dell.com>
Cc: bhelgaas@google.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, alexander.duyck@gmail.com,
Babu Moger <babu.moger@oracle.com>,
Hannes Reinecke <hare@suse.de>,
Michal Kubecek <mkubecek@suse.com>,
"Shane M. Seymour" <shane.seymour@hpe.com>,
Myron Stowe <myron.stowe@gmail.com>,
Venkat Duvvuru <VenkatKumar.Duvvuru@Emulex.com>
Subject: Re: [PATCH] Limit VPD length on Atheros wifi cards
Date: Fri, 8 Jan 2016 19:05:45 -0600 [thread overview]
Message-ID: <20160109010545.GA31085@localhost> (raw)
In-Reply-To: <20160109005736.GP5354@localhost>
[+cc Hannes, Michal, Shane, Myron, Venkat; sorry I missed you guys the
first time around]
On Fri, Jan 08, 2016 at 06:57:36PM -0600, Bjorn Helgaas wrote:
> [+cc Babu]
>
> Hi Jordan, Babu, et al,
>
> On Tue, Dec 29, 2015 at 04:19:02PM -0600, Jordan Hargrave wrote:
> > Attempt to read VPD on these cards causes kernel hang or delay
> >
> > Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
> > ---
> > drivers/pci/quirks.c | 10 ++++++++++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index e6376f6..a72667f 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -2161,6 +2161,16 @@ static void quirk_brcm_570x_limit_vpd(struct pci_dev *dev)
> > }
> > }
> >
> > +static void quirk_atheros_vpd(struct pci_dev *dev)
> > +{
> > + /* Atheros WiFi cards hang when reading VPD */
> > + if (dev->vpd)
> > + dev->vpd->len = 0;
> > +}
> > +
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATHEROS, PCI_ANY_ID, quirk_atheros_vpd);
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_atheros_vpd);
>
> We're accumulating several quirks like this, and they don't do
> anything device-specific, so we could probably use a single quirk for
> all of them, i.e., Babu's quirk_megaraid_sas_limit_vpd() and your
> quirk_atheros_vpd() are needlessly duplicated.
>
> I'd really like to have more details about what the "kernel hang or
> delay" that happens when we try to read VPD.
>
> Looking at pci_vpd_pci22_read(), it basically just does config
> accesses, so I only see two ways things could go wrong:
>
> 1) If the device responds with data, but the PCI_VPD_ADDR_F flag
> isn't set, we should be able to timeout gracefully.
>
> 2) If the device doesn't respond at all, we could see machine
> checks, master aborts, processor read timeouts, or similar hardware
> problems.
>
> If there are other failure modes, I'd like to learn what they are.
>
> If we're seeing problems like (1), there must be something we can
> improve in the way we handle timeouts.
>
> If we're seeing failures like (2), they're probably caused by a
> hardware or firmware problem on the device, and there's not much we
> can do in the kernel, so disabling VPD access completely is probably
> all we can do.
>
> So if/when we add quirks like this, I'm looking for bugzilla entries
> that clearly show that the problem is (2). I'd also like to log
> something in dmesg as a clue about why lspci or other utilities don't
> find any VPD data.
>
> Bjorn
>
> > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_BROADCOM,
> > PCI_DEVICE_ID_NX2_5706,
> > quirk_brcm_570x_limit_vpd);
next prev parent reply other threads:[~2016-01-09 1:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-29 22:19 [PATCH] Limit VPD length on Atheros wifi cards Jordan Hargrave
2016-01-09 0:57 ` Bjorn Helgaas
2016-01-09 1:05 ` Bjorn Helgaas [this message]
2016-01-09 23:15 ` Babu Moger
2016-01-11 21:13 ` [PATCH RFC] pci: Blacklist vpd access for buggy devices Babu Moger
2016-01-11 22:49 ` Babu Moger
2016-01-19 15:22 ` Jordan_Hargrave
2016-01-19 20:39 ` Babu Moger
2016-01-21 15:47 ` Jordan_Hargrave
2016-01-21 17:10 ` Babu Moger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160109010545.GA31085@localhost \
--to=helgaas@kernel.org \
--cc=Jordan_Hargrave@dell.com \
--cc=VenkatKumar.Duvvuru@Emulex.com \
--cc=alexander.duyck@gmail.com \
--cc=babu.moger@oracle.com \
--cc=bhelgaas@google.com \
--cc=hare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mkubecek@suse.com \
--cc=myron.stowe@gmail.com \
--cc=shane.seymour@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).