All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Jon Derrick <jonathan.derrick@intel.com>,
	Dongdong Liu <liudongdong3@huawei.com>,
	Sinan Kaya <okaya@kernel.org>,
	Oza Pawandeep <poza@codeaurora.org>,
	Matthew Wilcox <willy@infradead.org>,
	Lukas Wunner <lukas@wunner.de>, Christoph Hellwig <hch@lst.de>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] PCI/AER: Enable error reporting for all ports
Date: Fri, 19 Oct 2018 08:58:20 -0600	[thread overview]
Message-ID: <20181019145820.GB23571@localhost.localdomain> (raw)
In-Reply-To: <20181019011135.GP5906@bhelgaas-glaptop.roam.corp.google.com>

On Thu, Oct 18, 2018 at 08:11:35PM -0500, Bjorn Helgaas wrote:
> On Thu, Oct 18, 2018 at 05:03:13PM -0600, Keith Busch wrote:
> > On Thu, Oct 18, 2018 at 03:53:58PM -0500, Bjorn Helgaas wrote:
> > > Change the AER service driver so it binds to *all* PCIe Ports,
> > > including Switch Upstream and Downstream Ports.  Enable AER error
> > > reporting for all these Ports, but not for any children.
> > 
> > I'm looking at this again and think enabling/disabling error
> > reporting for ports is the responsibility of the port driver, not
> > the AER service.
> 
> That's an interesting idea.  Can you expand on this a little more?
> Why is it the responsibility of the port driver?
> 
> Do you think pci_enable_pcie_error_reporting() shouldn't be part of
> the AER service because it updates the Device Control register, which
> is in the PCIe Capability, not the AER Capability?
> 
> What about pci_aer_clear_device_status(), which clears Device Status,
> which is also in the PCIe Capability?

I was comparing how other end device driver's enable this, and they all call
pci_enable_pcie_error_reporting() somewhere along their pci_driver->probe
path. With that in mind, are ports special compared to end devices for this
particular feature?
 
> > The following should do the same as this patch, but without making
> > AER driver handle non-root ports.  The report enabling/disabling
> > functions are already stubbed for '!CONFIG_PCIE_AER' and have checks
> > for aer_cap and firmware first.
> 
> If we thought we should enable error reporting *always*, regardless of
> whether the AER service is enabled, this would make perfect sense to
> me, and I might suggest doing it in an even more generic place like
> pci_configure_device() or pci_init_capabilities().

There are unfortunately still pci_driver instances that don't implement
the err_handler callbacks, and may cause problems if we enable error
reporting in the device when its driver isn't capable of reacting to them.

If it wasn't for that, I think it would make more sense to move this
responsibility from drivers to the pci core.

> But that doesn't seem like where you're headed.  It seems like you
> still only want error reporting enabled when CONFIG_PCIEAR=y.  If
> that's the case, it seems like doing it in portdrv only obfuscates the
> connection with AER.  When CONFIG_PCIEAER is unset, the portdrv code
> *looks* like it's doing something but it's really not because of the
> #ifdef magic.

Right, but that's no different than every other Linux pci_driver. The
component that provides the pci_driver.err_handler should be responsible
for requesting to enable device error reporting, and that's provided by
the port driver, not AER.

      reply	other threads:[~2018-10-19 15:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 20:53 [PATCH v4] PCI/AER: Enable error reporting for all ports Bjorn Helgaas
2018-10-18 23:03 ` Keith Busch
2018-10-19  1:11   ` Bjorn Helgaas
2018-10-19 14:58     ` Keith Busch [this message]

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=20181019145820.GB23571@localhost.localdomain \
    --to=keith.busch@intel.com \
    --cc=hch@lst.de \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liudongdong3@huawei.com \
    --cc=lukas@wunner.de \
    --cc=mika.westerberg@linux.intel.com \
    --cc=okaya@kernel.org \
    --cc=poza@codeaurora.org \
    --cc=willy@infradead.org \
    /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.