Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Nirmal Patel <nirmal.patel@linux.intel.com>
Cc: Jon Derrick <jonathan.derrick@intel.com>, linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 1/2] PCI: vmd: Trigger secondary bus reset
Date: Tue, 20 Jul 2021 17:33:18 -0500	[thread overview]
Message-ID: <20210720223318.GA135757@bjorn-Precision-5520> (raw)
In-Reply-To: <20210720205009.111806-2-nirmal.patel@linux.intel.com>

On Tue, Jul 20, 2021 at 01:50:08PM -0700, Nirmal Patel wrote:
> During VT-d passthrough repetitive reboot tests, it was determined that the VMD
> domain needed to be reset in order to allow downstream devices to reinitialize
> properly. This is done using a secondary bus reset at each of the VMD root
> ports and any bridges in the domain.

I don't understand the "any bridges in the domain" part.  Clearly you
only reset Intel bridges, and only those on a single "bus".  So can
there be both VMD root ports and another kind of bridge on the same
bus?

Rewrap this to fit in 75 columns or so, so it doesn't overflow 80
column lines when git log indents it by 4.

> Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
> ---
>  drivers/pci/controller/vmd.c | 46 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index e3fcdfec58b3..6e1c60048774 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -15,6 +15,7 @@
>  #include <linux/srcu.h>
>  #include <linux/rculist.h>
>  #include <linux/rcupdate.h>
> +#include <linux/delay.h>
>  
>  #include <asm/irqdomain.h>
>  #include <asm/device.h>
> @@ -447,6 +448,49 @@ static struct pci_ops vmd_ops = {
>  	.write		= vmd_pci_write,
>  };
>  
> +#define PCI_HEADER_TYPE_MASK 0x7f

Already defined in include/uapi/linux/pci_regs.h.

> +#define PCI_CLASS_BRIDGE_PCI 0x0604

Already defined in include/linux/pci_ids.h.  What am I missing?  Seems
like you should see duplicate definition warnings.

> +#define DEVICE_SPACE (8 * 4096)
> +#define VMD_DEVICE_BASE(vmd, device) ((vmd)->cfgbar + (device) * DEVICE_SPACE)
> +#define VMD_FUNCTION_BASE(vmd, device, fn) ((vmd)->cfgbar + (device) * (DEVICE_SPACE + (fn*4096)))

Add blank line here.

> +static void vmd_domain_sbr(struct vmd_dev *vmd)
> +{
> +	char __iomem *base;
> +	u16 ctl;
> +	int dev_seq;
> +	int max_devs = resource_size(&vmd->resources[0]) * 32;
> +
> +	/*
> +	* Subdevice config space may or many not be mapped linearly using 4k config
> +	* space.

Fix comment indentation.

s/many/may/

I don't really understand the comment anyway.  Is the point that
subdevice config space may not be physically contiguous?  Certainly
VMD_DEVICE_BASE() computes virtual addresses that are linear.

> +	*/
> +	for (dev_seq = 0; dev_seq < max_devs; dev_seq++) {
> +		base = VMD_DEVICE_BASE(vmd, dev_seq);
> +		if (readw(base + PCI_VENDOR_ID) != PCI_VENDOR_ID_INTEL)
> +			continue;
> +
> +		if ((readb(base + PCI_HEADER_TYPE) & PCI_HEADER_TYPE_MASK) !=
> +		    PCI_HEADER_TYPE_BRIDGE)
> +			continue;
> +
> +		if (readw(base + PCI_CLASS_DEVICE) != PCI_CLASS_BRIDGE_PCI)
> +			continue;
> +
> +		/* pci_reset_secondary_bus() */
> +		ctl = readw(base + PCI_BRIDGE_CONTROL);
> +		ctl |= PCI_BRIDGE_CTL_BUS_RESET;
> +		writew(ctl, base + PCI_BRIDGE_CONTROL);
> +		readw(base + PCI_BRIDGE_CONTROL);
> +		msleep(2);

It's a shame we can't do this with pci_reset_secondary_bus().  Makes
me wonder if there's an opportunity for special pci_ops.

> +		ctl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> +		writew(ctl, base + PCI_BRIDGE_CONTROL);
> +		readw(base + PCI_BRIDGE_CONTROL);
> +
> +	}
> +	ssleep(1);
> +}
> +
>  static void vmd_attach_resources(struct vmd_dev *vmd)
>  {
>  	vmd->dev->resource[VMD_MEMBAR1].child = &vmd->resources[1];
> @@ -747,6 +791,8 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  	if (vmd->irq_domain)
>  		dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain);
>  
> +	vmd_domain_sbr(vmd);
> +
>  	pci_scan_child_bus(vmd->bus);
>  	pci_assign_unassigned_bus_resources(vmd->bus);
>  
> -- 
> 2.27.0
> 

  reply	other threads:[~2021-07-20 22:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 20:50 [PATCH v2 0/2] Issue secondary bus reset and domain window reset Nirmal Patel
2021-07-20 20:50 ` [PATCH v2 1/2] PCI: vmd: Trigger secondary bus reset Nirmal Patel
2021-07-20 22:33   ` Bjorn Helgaas [this message]
2021-07-22 18:39     ` Patel, Nirmal
2021-07-21  5:45   ` Christoph Hellwig
2021-07-22 18:45     ` Patel, Nirmal
2021-07-21  8:50   ` Pali Rohár
2021-07-22 18:44     ` Patel, Nirmal
2021-07-22 19:11     ` Bjorn Helgaas
2021-07-20 20:50 ` [PATCH v2 2/2] PCI: vmd: Issue vmd domain window reset Nirmal Patel
2021-07-20 22:42   ` Bjorn Helgaas
2021-07-22 18:47     ` Patel, Nirmal
2021-07-22 19:04       ` Bjorn Helgaas
2021-07-20 21:25 ` [PATCH v2 0/2] Issue secondary bus reset and " Patel, Nirmal

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=20210720223318.GA135757@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=nirmal.patel@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox