linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jon Derrick <jonathan.derrick@intel.com>, bhelgaas@google.com
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <helgaas@kernel.org>,
	Keith Busch <keith.busch@intel.com>
Subject: Re: [PATCH 2/2] PCI/VMD: Set up firmware-first if capable
Date: Wed, 17 Oct 2018 15:12:58 +0100	[thread overview]
Message-ID: <20181017140733.GA6674@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <1539650888-3792-3-git-send-email-jonathan.derrick@intel.com>

On Mon, Oct 15, 2018 at 06:48:08PM -0600, Jon Derrick wrote:
> The VMD endpoint device exposes a domain of root ports and any
> downstream devices attached to that hierarchy. VMD domains consisting of
> the root ports and downstream devices are not represented in the ACPI
> tables and _OSC is unsupported. Because of this non-standard way of
> signaling firmware-first enabling on the root ports, the VMD device
> instead advertises support for firmware-first on the root ports by
> setting its interface bit to 0x1.
> 
> When firmware-first is enabled on a VMD domain, the driver sets up the
> root port control registers to generate SMI system interrupts to
> firmware on errors. System firmware will handle the error as it sees
> fit, then passes back control to VMD with a synthesized MSI message.
> 
> Because of this kernel pass-back, the driver does not disable the native
> AER port service driver attached to the VMD root ports, allowing for
> further kernel error handling if desired.

This patch looks more like a policy to detect whether the generic
Root Port system error reporting should be enabled or not, or at
least may be generalized as such.

It is contained in the VMD driver - I would like to have Keith and Bjorn
opinions before merging it, see below.

> Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> ---
>  drivers/pci/controller/vmd.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index 46ed80f..9625dca 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -589,6 +589,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  	LIST_HEAD(resources);
>  	resource_size_t offset[2] = {0};
>  	resource_size_t membar2_offset = 0x2000, busn_start = 0;
> +	u8 interface;
>  
>  	/*
>  	 * Shadow registers may exist in certain VMD device ids which allow
> @@ -718,6 +719,35 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  	dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain);
>  	pci_rescan_bus(vmd->bus);
>  
> +	/*
> +	 * Certain VMD devices may request firmware-first error handling
> +	 * support on the domain. These domains are virtual and not described
> +	 * by ACPI and must be configured manually. VMD domains which utilize
> +	 * firmware-first may still require further kernel error handling, but
> +	 * the domain is intended to first interrupt upon error to system
> +	 * firmware before being passed back to the kernel. The system error
> +	 * handling bits in the root port control register must be enabled
> +	 * following the AER service driver configuration in order to generate
> +	 * these system interrupts.
> +	 *
> +	 * Because the root ports are not described by ACPI and _OSC is
> +	 * unsupported in VMD domains, the intent to use firmware-first error
> +	 * handling in the root ports is instead described by the VMD device's
> +	 * interface bit.
> +	 */
> +	pci_read_config_byte(vmd->dev, PCI_CLASS_PROG, &interface);
> +	if (interface == 0x1) {
> +		struct pci_dev *rpdev;
> +
> +		list_for_each_entry(rpdev, &vmd->bus->devices, bus_list) {
> +			if (rpdev->aer_cap)

This should be CONFIG_PCIEAER guarded but I would like to understand its
logic.

IIUC this assumes all devices in the root bus are root ports, which is
an VMD assumption I reckon.

> +				pcie_capability_set_word(rpdev, PCI_EXP_RTCTL,
> +							 PCI_EXP_RTCTL_SECEE  |
> +							 PCI_EXP_RTCTL_SENFEE |
> +							 PCI_EXP_RTCTL_SEFEE);

I wonder whether this code should be part of the generic AER layer (ie
the PCIE port driver) rather than VMD specific, after all that's part of
the generic specifications, I do not know if we can envisage an API that
allow PCI controller drivers to enable/disable system errors.

Thoughts ?

Lorenzo

> +		}
> +	}
> +
>  	WARN(sysfs_create_link(&vmd->dev->dev.kobj, &vmd->bus->dev.kobj,
>  			       "domain"), "Can't create symlink to domain\n");
>  	return 0;
> -- 
> 1.8.3.1
> 

  parent reply	other threads:[~2018-10-17 14:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16  0:48 [PATCH 0/2] VMD fixes for 4.20 Jon Derrick
2018-10-16  0:48 ` [PATCH 1/2] PCI/VMD: Detach resources after stopping root bus Jon Derrick
2018-10-16 14:48   ` Keith Busch
2018-10-18 16:43   ` Lorenzo Pieralisi
2018-10-16  0:48 ` [PATCH 2/2] PCI/VMD: Set up firmware-first if capable Jon Derrick
2018-10-16  2:25   ` kbuild test robot
2018-10-17 14:12   ` Lorenzo Pieralisi [this message]
2018-10-17 18:16     ` Derrick, Jonathan
2018-10-17 23:01       ` Bjorn Helgaas

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=20181017140733.GA6674@e107981-ln.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=linux-pci@vger.kernel.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 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).