[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c773081eadb89c4b4317d0a709a06a7d@codeaurora.org>
Date: Fri, 19 Jan 2018 09:53:50 +0530
From: poza@...eaurora.org
To: Sinan Kaya <okaya@...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>,
Keith Busch <keith.busch@...el.com>, Wei Zhang <wzhang@...com>,
Timur Tabi <timur@...eaurora.org>
Subject: Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 23:33, Sinan Kaya wrote:
> On 1/18/2018 1:00 PM, poza@...eaurora.org wrote:
>>> I think you would put into include/linux/pci.h only if there is an
>>> external
>>> use of constant outside of drivers/pci directory. Otherwise, you
>>> should keep
>>> the setting inside one of the header files in drivers/pci directory.
>>>
>>> I don't see any other subsystem caring about DPC_FATAL definition.
>>
>> ok so you are suggesting to move only DPC_FATAL ? so then AER can stay
>> where it is.
>
> Now that both AER and DPC handling is getting unified, I think it makes
> sense to
> keep all error codes (AER+DPC) together in drivers/pci/pci.h rather
> than having
> them split in aer.h and dpc.h.
>
> Otherwise, how would we avoid having a new error type defined with the
> existing values.
I agree, its is just that drivers/acpi/apet/ghes.c has to do
#include ../../pci/pci.h
but thats okay I think. let me move error codes to drivers/pci/pci.h.
Regards,
Oza.
Powered by blists - more mailing lists