All of lore.kernel.org
 help / color / mirror / Atom feed
From: Betty Dall <betty.dall@hp.com>
To: "Pearson, Greg" <greg.pearson@hp.com>
Cc: "rjw@sisk.pl" <rjw@sisk.pl>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"ying.huang@intel.com" <ying.huang@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 3/3] PCI/AER: Provide reset_link for firmware first root port
Date: Wed, 29 May 2013 10:16:32 -0600	[thread overview]
Message-ID: <1369844192.12792.3.camel@ejdallLaptop> (raw)
In-Reply-To: <51A621E2.2050202@hp.com>

On Wed, 2013-05-29 at 09:42 -0600, Pearson, Greg wrote:
> On 05/28/2013 12:48 PM, Betty Dall wrote:
> > The firmware first path does not install the aerdrv root port
> > service driver, so the firmware first root port does not have
> > a reset_link callback. When a firmware first root port does not have
> > a reset_link callback, use a new default reset_link similar to what
> > we already do for the default_downstream_reset_link(). The firmware
> > first default reset_link brings the root port out of SBR if firmware
> > left it in SBR.
> >
> > Signed-off-by: Betty Dall <betty.dall@hp.com>
> > ---
> >
> >   drivers/pci/pcie/aer/aerdrv_core.c |   37 ++++++++++++++++++++++++++++++++++++
> >   1 files changed, 37 insertions(+), 0 deletions(-)
> >
> >
> > diff --git a/drivers/pci/pcie/aer/aerdrv_core.c b/drivers/pci/pcie/aer/aerdrv_core.c
> > index 8ec8b4f..6862fe3 100644
> > --- a/drivers/pci/pcie/aer/aerdrv_core.c
> > +++ b/drivers/pci/pcie/aer/aerdrv_core.c
> > @@ -413,6 +413,40 @@ static pci_ers_result_t default_downstream_reset_link(struct pci_dev *dev)
> >   	return PCI_ERS_RESULT_RECOVERED;
> >   }
> >   
> > +/**
> > + * default_ff_root_port_reset_link - default reset function for firmware
> > + *		first Root Port
> > + * @dev: pointer to root port's pci_dev data structure
> > + *
> > + * Invoked when performing link reset at Root Port w/ no aer driver.
> > + * This happens through the firmware first path. Firmware may leave
> > + * the Root Port in SBR and it is the OS responsiblity to bring it out
> > + * of SBR.
> > + */
> > +static pci_ers_result_t default_ff_root_port_reset_link(struct pci_dev *dev)
> > +{
> > +	u16 p2p_ctrl;
> > +
> > +	/* Read Secondary Bus Reset */
> > +	pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &p2p_ctrl);
> > +	p2p_ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
> 
> Remove "p2p_ctrl |= PCI_BRIDGE_CTL_BUS_RESET;" otherwise the following 
> conditional is always taken.
> 
> --
> Greg

Agreed. That was a copy and paste mistake. I will fix and retest.

-Betty

> > +
> > +	/* De-assert Secondary Bus Reset, if it is set */
> > +	if (p2p_ctrl & PCI_BRIDGE_CTL_BUS_RESET) {
> > +		p2p_ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
> > +		pci_write_config_word(dev, PCI_BRIDGE_CONTROL, p2p_ctrl);
> > +
> > +		/*
> > +		 * System software must wait for at least 100ms from the end
> > +		 * of a reset of one or more device before it is permitted
> > +		 * to issue Configuration Requests to those devices.
> > +		 */
> > +		msleep(200);
> > +		dev_dbg(&dev->dev, "Root Port link has been reset\n");
> > +	}
> > +	return PCI_ERS_RESULT_RECOVERED;
> > +}
> > +
> >   static int find_aer_service_iter(struct device *device, void *data)
> >   {
> >   	struct pcie_port_service_driver *service_driver, **drv;
> > @@ -460,6 +494,9 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)
> >   		status = driver->reset_link(udev);
> >   	} else if (pci_pcie_type(udev) == PCI_EXP_TYPE_DOWNSTREAM) {
> >   		status = default_downstream_reset_link(udev);
> > +	} else if (pci_pcie_type(udev) == PCI_EXP_TYPE_ROOT_PORT &&
> > +		pcie_aer_get_firmware_first(udev)) {
> > +		status = default_ff_root_port_reset_link(udev);
> >   	} else {
> >   		dev_printk(KERN_DEBUG, &dev->dev,
> >   			"no link-reset support at upstream device %s\n",
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

      reply	other threads:[~2013-05-29 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 18:48 [PATCH 0/3] PCI/ACPI: Fix firmware first error recovery with root port in reset Betty Dall
2013-05-28 18:48 ` [PATCH 1/3] PCI/AER: Fix incorrect return from aer_hest_parse() Betty Dall
2013-05-28 18:48 ` [PATCH 2/3] ACPI/APEI: Force fatal AER severity when bus has been reset Betty Dall
2013-05-29 15:42   ` Pearson, Greg
2013-05-29 16:16     ` Betty Dall
2013-05-28 18:48 ` [PATCH 3/3] PCI/AER: Provide reset_link for firmware first root port Betty Dall
2013-05-29 15:42   ` Pearson, Greg
2013-05-29 16:16     ` Betty Dall [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=1369844192.12792.3.camel@ejdallLaptop \
    --to=betty.dall@hp.com \
    --cc=bhelgaas@google.com \
    --cc=greg.pearson@hp.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=ying.huang@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.