From: Matt Domsch <Matt_Domsch@dell.com>
To: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
Tom Long Nguyen <tom.l.nguyen@intel.com>,
Zhang Yanmin <yanmin.zhang@intel.com>,
linux-kernel@vger.kernel.org,
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
Huong_Nguyen@dell.com
Subject: Re: [PATCH] PCIe AER: honor ACPI HEST FIRMWARE FIRST mode
Date: Thu, 29 Oct 2009 21:53:14 -0500 [thread overview]
Message-ID: <20091030025313.GA1042@mock.linuxdev.us.dell.com> (raw)
In-Reply-To: <4AEA4C82.6010604@jp.fujitsu.com>
On Fri, Oct 30, 2009 at 11:16:34AM +0900, Hidetoshi Seto wrote:
> Hi Matt,
>
> Sorry to late response.
Thank you for your review.
> Matt Domsch wrote:
> > + /* These three should never appear */
> > + case ACPI_HEST_TYPE_NOT_USED3:
> > + case ACPI_HEST_TYPE_NOT_USED4:
> > + case ACPI_HEST_TYPE_NOT_USED5:
> > + break;
>
> Yes, these should never. But if there, what will happen?
> I'd like to see a error message rather than hang in infinite loops.
>
> > + /* These should never appear either */
> > + case ACPI_HEST_TYPE_RESERVED:
> > + default:
> > + break;
>
> Ditto.
It won't infinite loop, due to i incrementing. If one of these types
appears early in the error_source list, it would prevent us from
seeing the (correct) source types later in the list.
But we can't advance the pointer because we can't know by how much to
advance it. We could print a debug message. How about:
printk(KERN_DEBUG PREFIX
"HEST Error Source list contains an obsolete type.\n");
At some point, the RESERVED type will move to higher number as new
sources are defined in the spec, so that would be different message.
How about:
printk(KERN_DEBUG PREFIX
"HEST Error Source list contains a reserved type.\n");
and I'll have it print only once.
> > +int acpi_hest_firmware_first_pci(struct pci_dev *pci)
> > +{
>
> It is OK, but if args of this function were (bus_n, dev_n, fn_n)
> then "#include <linux/pci.h>" will not be required.
I prefer to pass the pci_dev rather than 3 or 4 parts thereof down
through the functions. Several other .c files in drivers/acpi do
likewise.
> One another concern I got here is if there was a seg_n, segment
> number, how we can handle it... but it will be one of future works,
> so this would be OK at this time.
Yes, but this ACPI table doesn't have a domain / segment number in
it. Does this test:
if (p->flags & ACPI_HEST_FIRMWARE_FIRST &&
(p->flags & ACPI_HEST_GLOBAL ||
(p->bus == pci->bus->number &&
p->device == PCI_SLOT(pci->devfn) &&
p->function == PCI_FUNC(pci->devfn))))
*firmware_first = 1;
need to add an explicit test for && 0 == pci_domain_nr(pci->bus) ?
> > @@ -35,6 +36,9 @@ int pci_enable_pcie_error_reporting(struct pci_dev *dev)
> > u16 reg16 = 0;
> > int pos;
> >
> > + if (dev->aer_firmware_first)
> > + return -EIO;
> > +
>
> The aer_init() will be called for root ports (via aer_probe() of
> aer service driver), but not for end point devices or so on.
> So you need to call aer_init() for end points from here or somewhere
> else, to set aer_firmware_first correctly.
Good catch. I'll move the setting of dev->aer_firmware_first into the
PCI device discovery path. By that point, ACPI is configured and
available.
> > + if (acpi_hest_firmware_first_pci(dev->port)) {
> > + dev_printk(KERN_DEBUG, &dev->device,
> > + "PCIe device errors handled by platform firmware.\n");
> > + dev->port->aer_firmware_first=1;
>
> Coding style requests you to add spaces before and after of "=".
OK. This and the next will move as noted above.
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
next prev parent reply other threads:[~2009-10-30 2:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-06 17:33 [PATCH] PCIe AER: honor ACPI HEST FIRMWARE FIRST mode Matt Domsch
2009-10-08 0:59 ` Hidetoshi Seto
[not found] ` <851fc09e0910082221q7f832c22xfc0d01ab72a97c3f@mail.gmail.com>
2009-10-09 5:55 ` Fwd: " Huang Ying
2009-10-09 14:31 ` Matt Domsch
2009-10-09 7:11 ` Kenji Kaneshige
2009-10-09 18:28 ` Matt Domsch
2009-10-09 18:33 ` Matt Domsch
2009-10-29 14:15 ` Matt Domsch
2009-10-29 16:48 ` Jesse Barnes
2009-10-30 2:16 ` Hidetoshi Seto
2009-10-30 2:53 ` Matt Domsch [this message]
2009-10-30 3:24 ` Hidetoshi Seto
2009-11-02 17:51 ` Matt Domsch
2009-11-04 17:11 ` Jesse Barnes
2009-11-04 20:55 ` Yinghai Lu
2009-11-04 20:55 ` Yinghai Lu
2009-11-04 21:05 ` Jesse Barnes
2009-11-04 21:07 ` Jesse Barnes
2009-11-04 21:07 ` Jesse Barnes
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=20091030025313.GA1042@mock.linuxdev.us.dell.com \
--to=matt_domsch@dell.com \
--cc=Huong_Nguyen@dell.com \
--cc=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=tom.l.nguyen@intel.com \
--cc=yanmin.zhang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.