All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@kernel.org>
To: Dongdong Liu <liudongdong3@huawei.com>,
	Keith Busch <keith.busch@intel.com>
Cc: "helgaas@kernel.org" <helgaas@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linuxarm@huawei.com" <linuxarm@huawei.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	tanxiaofei <tanxiaofei@huawei.com>
Subject: Re: [PATCH] PCI/ERR: Fix run error recovery callbacks for all affected devices
Date: Mon, 28 Jan 2019 10:47:49 -0500	[thread overview]
Message-ID: <7a2ee482-9f77-0295-6540-e41d85b04297@kernel.org> (raw)
In-Reply-To: <2623f4f8-a832-c517-e5a5-7df2af57bc07@huawei.com>

On 1/28/2019 9:54 AM, Dongdong Liu wrote:
>> In this case the AER error status of other functions should not report any
>> outstanding event. Please verify this. Otherwise, you are looking at a device quirk. 
>>
> 
> Agree, multiple errors bit can be set, AER driver or firmware will collect the error 
> 
> devices and call pcie_do_recovery() for every error devices.

pcie_do_recovery() is also being called for non-firmware first scenario where OS
has no prior knowledge of which devices are in fault.

> 
> also have different PFs (device numbers are different) under the same bus.
> This case do not need to brodcast all the devices under the same bus.

Even if OS was to call pcie_do_recovery() for other devices, nothing should
happen because the expectation for other devices' AER status register to report
no errors. This is the case we want you to validate. If this is not true, you
are looking at a firmware/HW bug.

  reply	other threads:[~2019-01-28 17:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 13:50 [PATCH] PCI/ERR: Fix run error recovery callbacks for all affected devices Dongdong Liu
2019-01-24 18:18 ` Sinan Kaya
2019-01-24 21:37   ` Keith Busch
2019-01-25 14:28     ` Dongdong Liu
2019-01-25 17:09       ` Sinan Kaya
2019-01-28 14:05         ` Dongdong Liu
2019-01-25 17:17       ` Keith Busch
2019-01-25 17:37         ` Sinan Kaya
2019-01-25 17:46           ` Keith Busch
2019-01-25 17:46           ` Sinan Kaya
2019-01-28 14:54             ` Dongdong Liu
2019-01-28 15:47               ` Sinan Kaya [this message]
2019-01-28 16:15                 ` Sinan Kaya

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=7a2ee482-9f77-0295-6540-e41d85b04297@kernel.org \
    --to=okaya@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=keith.busch@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liudongdong3@huawei.com \
    --cc=tanxiaofei@huawei.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.