From: Sinan Kaya <okaya@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>, Oza Pawandeep <poza@codeaurora.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Philippe Ombredanne <pombredanne@nexb.com>,
Thomas Gleixner <tglx@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kate Stewart <kstewart@linuxfoundation.org>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Dongdong Liu <liudongdong3@huawei.com>,
Keith Busch <keith.busch@intel.com>, Wei Zhang <wzhang@fb.com>,
Timur Tabi <timur@codeaurora.org>
Subject: Re: [PATCH v13 6/6] PCI/DPC: Do not do recovery for hotplug enabled system
Date: Wed, 11 Apr 2018 21:41:56 -0400 [thread overview]
Message-ID: <13efe2e8-74c8-acb4-ec58-f79b14a1f182@codeaurora.org> (raw)
In-Reply-To: <20180410210349.GG54986@bhelgaas-glaptop.roam.corp.google.com>
On 4/10/2018 5:03 PM, Bjorn Helgaas wrote:
>> DPC and AER should attempt recovery in the same way, except the
>> cases where system is with hotplug enabled.
> What's the connection with hotplug? I see from the patch that for
> hotplug bridges you remove the tree below the bridge, and otherwise
> you just reset the secondary link (I think).
>
> The changelog should explain why we need the difference.
>
> I'm a little skeptical to begin with, because I'm not sure why we
> should handle a DPC event differently just because a bridge has the
> *capability* of hotplug. Even if a hotplug bridge reports a DPC
> event, that doesn't necessarily mean a hotplug has occurred.
>
Let's do a recap on what we have discussed about this until now.
There are two conflicting error recovery mechanisms for PCIe.
If a system supports both hotplug and DPC, endpoint can be removed and inserted safely.
DPC driver shuts down the driver on link down. When link comes back up,
hotplug driver takes over and initiates an enumeration process.
Keith mentioned the stop and re-enumerate design was chosen because
someone could remove a drive and insert an unrelated drive back to the
system. We can't really save and restore state as we do in the AER path.
Now, let's assume a system without hotplug capability.
Second mechanism is to go through DPC/AER path and do an automatic link
down recovery via DPC retrain/secondary bus reset including register save and
restore. Second mechanism is more suitable for handling "surprise link down"
event. The goal is to retrain the link and continue driver operation.
The goal of this patch to separate these two cases from each other as
the DPC driver needs to work on both contexts. Current DPC code doesn't handle
the second use case.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2018-04-12 1:41 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 14:41 [PATCH v13 0/6] Address error and recovery for AER and DPC Oza Pawandeep
2018-04-09 14:41 ` [PATCH v13 1/6] PCI/AER: Rename error recovery to generic PCI naming Oza Pawandeep
2018-04-09 23:14 ` Keith Busch
2018-04-09 14:41 ` [PATCH v13 2/6] PCI/AER: Factor out error reporting from AER Oza Pawandeep
2018-04-09 23:15 ` Keith Busch
2018-04-10 11:36 ` kbuild test robot
2018-04-09 14:41 ` [PATCH v13 3/6] PCI/PORTDRV: Implement generic find service Oza Pawandeep
2018-04-09 23:15 ` Keith Busch
2018-04-09 14:41 ` [PATCH v13 4/6] PCI/DPC: Unify and plumb error handling into DPC Oza Pawandeep
2018-04-09 23:29 ` Keith Busch
2018-04-09 23:51 ` Sinan Kaya
2018-04-10 0:05 ` Sinan Kaya
2018-04-09 14:41 ` [PATCH v13 5/6] PCI: Unify wait for link active into generic PCI Oza Pawandeep
2018-04-09 23:25 ` Keith Busch
2018-04-12 8:40 ` poza
2018-04-09 14:41 ` [PATCH v13 6/6] PCI/DPC: Do not do recovery for hotplug enabled system Oza Pawandeep
2018-04-10 21:03 ` Bjorn Helgaas
2018-04-12 1:41 ` Sinan Kaya [this message]
2018-04-12 14:06 ` Bjorn Helgaas
2018-04-12 14:34 ` Sinan Kaya
2018-04-12 14:39 ` Keith Busch
2018-04-12 15:02 ` Keith Busch
2018-04-12 16:27 ` Sinan Kaya
2018-04-12 17:09 ` Keith Busch
2018-04-12 17:41 ` Sinan Kaya
2018-04-14 15:53 ` Sinan Kaya
2018-04-16 3:17 ` Bjorn Helgaas
2018-04-16 5:33 ` poza
2018-04-16 5:51 ` poza
2018-04-16 14:01 ` Bjorn Helgaas
2018-04-16 14:46 ` Sinan Kaya
2018-04-16 17:15 ` poza
2018-04-16 3:16 ` [PATCH v13 0/6] Address error and recovery for AER and DPC Bjorn Helgaas
2018-04-16 3:53 ` Sinan Kaya
2018-04-16 6:03 ` poza
2018-04-16 13:27 ` Bjorn Helgaas
2018-04-16 14:12 ` poza
2018-04-16 14:30 ` 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=13efe2e8-74c8-acb4-ec58-f79b14a1f182@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=keith.busch@intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=pombredanne@nexb.com \
--cc=poza@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=timur@codeaurora.org \
--cc=wzhang@fb.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;
as well as URLs for NNTP newsgroup(s).