[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b819352-3efc-002c-897b-2d8536c92d94@codeaurora.org>
Date: Tue, 2 Jan 2018 14:09:13 -0500
From: Sinan Kaya <okaya@...eaurora.org>
To: Bjorn Helgaas <helgaas@...nel.org>,
Oza Pawandeep <poza@...eaurora.org>
Cc: 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>,
Gabriele Paoloni <gabriele.paoloni@...wei.com>,
Keith Busch <keith.busch@...el.com>, Wei Zhang <wzhang@...com>,
Timur Tabi <timur@...eaurora.org>
Subject: Re: [PATCH v2 0/4] Address error and recovery for AER and DPC
On 1/2/2018 2:02 PM, Bjorn Helgaas wrote:
> I read that as suggesting that we should enable DPC support in Linux
> if and only if we also enable AER. But I don't see anything in DPC
> that looks like that. Should there be something there? Should DPC be
> restructured so it's enabled and handled inside the AER driver instead
> of being a separate driver?
I think Keith posted a patch to do this. If firmware first is enabled, DPC
init is skipped after his patch.
Oza was able to plumb the DPC handling into error recovery callbacks of
the portdrv since the portdrv layer already provides this facilities such
as reset_link and resume.
The way DPC and AER works is almost identical from AER portdrv perspective.
I really like his plumbing. Putting DPC code into AER makes it more
convoluted in my opinion.
--
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