public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Kuppuswamy, Sathyanarayanan"  <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Yicong Yang <yangyicong@hisilicon.com>, bhelgaas@google.com
Cc: jay.vosburgh@canonical.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, ashok.raj@intel.com
Subject: Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices
Date: Wed, 27 May 2020 20:57:23 -0700	[thread overview]
Message-ID: <7b15ffd4-ac9b-6753-63a7-dc6e2bfa30c8@linux.intel.com> (raw)
In-Reply-To: <a4bb15a1-2524-b4f7-524b-840ae41f9b49@hisilicon.com>



On 5/26/20 11:41 PM, Yicong Yang wrote:
>>> We should do slot reset if driver required, but it's different from the `slot reset` in pci_bus_error_reset().
>>> Previously we don't do a slot reset and call ->slot_reset() directly, I don't know the certain reason.
>> IIUC, your concern is whether it is correct to trigger reset for
>> pci_channel_io_normal case right ? Please correct me if my
>> assumption is incorrect.
> right.
> 
>> If its true, then why would report_error_detected() will return
>> PCI_ERS_*_NEED_RESET for pci_channel_io_normal case ? If
>> report_error_detected() requests reset in pci_channel_io_normal
>> case then I think we should give preference to it.
> If we get PCI_ERS_*_NEED_RESET, we should do slot reset, no matter it's a
> hotpluggable slot or not.

pci_slot_reset() function itself has dependency on hotplug ops. So
what kind of slot reset is needed for non-hotplug case?

static int pci_slot_reset(struct pci_slot *slot, int probe)
{
	int rc;

	if (!slot || !pci_slot_resetable(slot))
		return -ENOTTY;

	if (!probe)
		pci_slot_lock(slot);

	might_sleep();

	rc = pci_reset_hotplug_slot(slot->hotplug, probe);

	if (!probe)
		pci_slot_unlock(slot);

	return rc;
}

static int pci_reset_hotplug_slot(struct hotplug_slot *hotplug, int probe)
{
	int rc = -ENOTTY;

	if (!hotplug || !try_module_get(hotplug->owner))
		return rc;

	if (hotplug->ops->reset_slot)
		rc = hotplug->ops->reset_slot(hotplug, probe);

	module_put(hotplug->owner);

	return rc;
}
   And we shouldn't do it here in reset_link(), that's
> two separate things.  The `slot reset` done in aer_root_reset() is only for *link
> reset*, as there may have some side effects to perform secondary bus reset directly
> for hotpluggable slot, as mentioned in commit c4eed62a2143, so it use slot reset
> to do the reset link things.
> 
> As for slot reset required by the driver, we should perform it later just before the
> ->slot_reset(). I noticed the TODO comments there and we should implement
> it if it's necessary.
I agree.
> 
> It lies in line 183, drivers/pcie/err.c:
> 
>      if (status == PCI_ERS_RESULT_NEED_RESET) {
>          /*
>           * TODO: Should call platform-specific
>           * functions to reset slot before calling
>           * drivers' slot_reset callbacks?
>           */
>          status = PCI_ERS_RESULT_RECOVERED;
>          pci_dbg(dev, "broadcast slot_reset message\n");
>          pci_walk_bus(bus, report_slot_reset, &status);
>      }
> 
> 

      reply	other threads:[~2020-05-28  3:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <18609.1588812972@famine>
2020-05-07  3:32 ` [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices sathyanarayanan.kuppuswamy
2020-05-12 19:20   ` Jay Vosburgh
2020-05-13  1:50     ` Yicong Yang
2020-05-13 22:44   ` Bjorn Helgaas
2020-05-14 20:36     ` Kuppuswamy, Sathyanarayanan
2020-05-20  8:28   ` Yicong Yang
2020-05-20 17:04     ` Kuppuswamy, Sathyanarayanan
2020-05-21 10:58       ` Yicong Yang
2020-05-21 19:31         ` Kuppuswamy, Sathyanarayanan
2020-05-22  2:56           ` Yicong Yang
2020-05-27  1:31             ` Kuppuswamy, Sathyanarayanan
2020-05-27  3:00               ` Oliver O'Halloran
2020-05-27  3:06                 ` Kuppuswamy, Sathyanarayanan
2020-05-27  3:35                   ` Oliver O'Halloran
2020-05-27  3:50               ` Yicong Yang
2020-05-27  4:04                 ` Kuppuswamy, Sathyanarayanan
2020-05-27  6:41                   ` Yicong Yang
2020-05-28  3:57                     ` Kuppuswamy, Sathyanarayanan [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=7b15ffd4-ac9b-6753-63a7-dc6e2bfa30c8@linux.intel.com \
    --to=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=bhelgaas@google.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=yangyicong@hisilicon.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