Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jon Derrick <jonathan.derrick@intel.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 1/2] PCI: vmd: Trigger secondary bus reset
Date: Thu, 22 Jul 2021 14:11:57 -0500	[thread overview]
Message-ID: <20210722191157.GA328153@bjorn-Precision-5520> (raw)
In-Reply-To: <20210721085026.aue5snnynlqw6r46@pali>

On Wed, Jul 21, 2021 at 10:50:26AM +0200, Pali Rohár wrote:
> On Tuesday 20 July 2021 13:50:08 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.
> > 
> > Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> > Reviewed-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> >  drivers/pci/controller/vmd.c | 46 ++++++++++++++++++++++++++++++++++++

> > +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.
> > +	*/
> > +	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);
> > +
> > +		ctl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> > +		writew(ctl, base + PCI_BRIDGE_CONTROL);
> > +		readw(base + PCI_BRIDGE_CONTROL);
> 
> You cannot unconditionally call secondary bus reset for arbitrary PCIe
> Bridge. Calling it breaks more PCIe devices behind bridge and
> pci_reset_secondary_bus() already handles it and skip reset if reset is
> causing issues.
> 
> I would suggest to use pci_reset_secondary_bus() and extend it
> so you can call it also from your driver.

Are you referring to PCI_DEV_FLAGS_NO_BUS_RESET?  That's handled in
pci_parent_bus_reset(), not pci_reset_secondary_bus().

I would probably agree that PCI_DEV_FLAGS_NO_BUS_RESET *should* be
checked in pci_reset_secondary_bus(), since there are several paths to
get there without going through pci_parent_bus_reset().

> > +	}
> > +	ssleep(1);
> > +}

  parent reply	other threads:[~2021-07-22 19:12 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
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 [this message]
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=20210722191157.GA328153@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=nirmal.patel@linux.intel.com \
    --cc=pali@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