[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57d0b245-aecb-1518-c8bb-df8b69a86bcc@codeaurora.org>
Date: Mon, 12 Mar 2018 13:41:07 -0400
From: Sinan Kaya <okaya@...eaurora.org>
To: Keith Busch <keith.busch@...el.com>, poza@...eaurora.org
Cc: Bjorn Helgaas <helgaas@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Philippe Ombredanne <pombredanne@...b.com>,
Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kate Stewart <kstewart@...uxfoundation.org>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
Dongdong Liu <liudongdong3@...wei.com>,
Wei Zhang <wzhang@...com>, Timur Tabi <timur@...eaurora.org>,
linux-pci-owner@...r.kernel.org
Subject: Re: [PATCH v12 0/6] Address error and recovery for AER and DPC
I was just writing a reply to you. You acted first :)
On 3/12/2018 1:33 PM, Keith Busch wrote:
>>> After releasing a slot from DPC, the link is allowed to retrain. If
>>> there
>>> is a working device on the other side, a link up event occurs. That
>>> event is handled by the pciehp driver, and that schedules enumeration
>>> no matter what you do to the DPC driver.
>> yes, that is what i current, but this patch-set makes DPC aware of error
>> handling driver callbacks.
> I've been questioning the utility of doing that since the very first
> version of this patch set.
>
I think we should all agree that shutting down the device drivers with active
work is not safe. There could be outstanding work that the endpoint driver
needs to take care of.
That was the motivation for this change so that we give endpoint drivers an
error callback when something goes wrong.
The rest is implementation detail that we can all figure out.
--
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.
Powered by blists - more mailing lists