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);
> }
>
>
prev parent 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