Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-19 10:14, Sinan Kaya wrote: On 1/18/2018 11:23 PM, p...@codeaurora.org wrote: On 2018-01-18 23:33, Sinan Kaya wrote: On 1/18/2018 1:00 PM, p...@codeaurora.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 That's bad. I was just thinking about the DPC error code only. I didn't realize AER error codes are being referenced from ghes.c. but thats okay I think. let me move error codes to drivers/pci/pci.h. It is better if error codes move to include/linux/pci.h and keep them together. The problem with moving them to include/linux/pci.h, it falls into global scope, besides they have to be renamed to/prefixed with PCI_ERR_xxx the use of AER_FATAL, DPC_FATAL etc.. is very limited in entire linux. and likely to be so. I think moving them to drivers/pci/pci.h would be more restricted/local let me make patch-set based on that, and see how it looks like. we can arrive at some consensus then. Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-19 10:14, Sinan Kaya wrote: On 1/18/2018 11:23 PM, p...@codeaurora.org wrote: On 2018-01-18 23:33, Sinan Kaya wrote: On 1/18/2018 1:00 PM, p...@codeaurora.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 That's bad. I was just thinking about the DPC error code only. I didn't realize AER error codes are being referenced from ghes.c. but thats okay I think. let me move error codes to drivers/pci/pci.h. It is better if error codes move to include/linux/pci.h and keep them together. The problem with moving them to include/linux/pci.h, it falls into global scope, besides they have to be renamed to/prefixed with PCI_ERR_xxx the use of AER_FATAL, DPC_FATAL etc.. is very limited in entire linux. and likely to be so. I think moving them to drivers/pci/pci.h would be more restricted/local let me make patch-set based on that, and see how it looks like. we can arrive at some consensus then. Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 11:23 PM, p...@codeaurora.org wrote: > On 2018-01-18 23:33, Sinan Kaya wrote: >> On 1/18/2018 1:00 PM, p...@codeaurora.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 That's bad. I was just thinking about the DPC error code only. I didn't realize AER error codes are being referenced from ghes.c. > > but thats okay I think. let me move error codes to drivers/pci/pci.h. It is better if error codes move to include/linux/pci.h and keep them together. > > Regards, > Oza. > -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 11:23 PM, p...@codeaurora.org wrote: > On 2018-01-18 23:33, Sinan Kaya wrote: >> On 1/18/2018 1:00 PM, p...@codeaurora.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 That's bad. I was just thinking about the DPC error code only. I didn't realize AER error codes are being referenced from ghes.c. > > but thats okay I think. let me move error codes to drivers/pci/pci.h. It is better if error codes move to include/linux/pci.h and keep them together. > > Regards, > Oza. > -- 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.
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, p...@codeaurora.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.
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, p...@codeaurora.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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 1:00 PM, p...@codeaurora.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. -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 1:00 PM, p...@codeaurora.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. -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 22:01, Sinan Kaya wrote: On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: On 2018-01-18 10:47, p...@codeaurora.org wrote: On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza. Should I be doing in next patch-set series ? 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 22:01, Sinan Kaya wrote: On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: On 2018-01-18 10:47, p...@codeaurora.org wrote: On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza. Should I be doing in next patch-set series ? 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: > On 2018-01-18 10:47, p...@codeaurora.org wrote: >> On 2018-01-17 22:16, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + >>> >>> can you keep this in drivers/pci.h and get rid of this file? >> >> I thought about this, but if I keep it in drivers/pci.h, >> then AER's defines have to be in that as well. (for unification) >> >> and then all the dependent files who are using AER_FATAL such as >> drivers/acpi/apei/ghees.c >> have to go on including this drivers file which is odd way of doing it. >> >> So I am not very sure about thissince AER_FATAL are in aer.h, I >> have made dpc.h >> >> >> Regards, >> Oza. > > Should I be doing in next patch-set series ? > 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. -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/18/2018 12:57 AM, p...@codeaurora.org wrote: > On 2018-01-18 10:47, p...@codeaurora.org wrote: >> On 2018-01-17 22:16, Sinan Kaya wrote: >>> On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + >>> >>> can you keep this in drivers/pci.h and get rid of this file? >> >> I thought about this, but if I keep it in drivers/pci.h, >> then AER's defines have to be in that as well. (for unification) >> >> and then all the dependent files who are using AER_FATAL such as >> drivers/acpi/apei/ghees.c >> have to go on including this drivers file which is odd way of doing it. >> >> So I am not very sure about thissince AER_FATAL are in aer.h, I >> have made dpc.h >> >> >> Regards, >> Oza. > > Should I be doing in next patch-set series ? > 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. -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 10:52, p...@codeaurora.org wrote: On 2018-01-17 22:15, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: + driver = pci_find_dpc_service(udev); +#endif #if IS_ENABLED(CONFIG_PCIEAER) - /* Use the aer driver of the component firstly */ - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. Right now, find_xxx_service are in their respective file and exporting it. which makes sense no less than having generic function. If I have to change pci_find_service(, int service_name) then it has to be somewhere in generic file. probably portdrv_core.c either way I am fine but just thinking out if its really required. Regards, Oza. Should I be doing in next patch-set series ? Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 10:52, p...@codeaurora.org wrote: On 2018-01-17 22:15, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: + driver = pci_find_dpc_service(udev); +#endif #if IS_ENABLED(CONFIG_PCIEAER) - /* Use the aer driver of the component firstly */ - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. Right now, find_xxx_service are in their respective file and exporting it. which makes sense no less than having generic function. If I have to change pci_find_service(, int service_name) then it has to be somewhere in generic file. probably portdrv_core.c either way I am fine but just thinking out if its really required. Regards, Oza. Should I be doing in next patch-set series ? Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 10:47, p...@codeaurora.org wrote: On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza. Should I be doing in next patch-set series ?
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-18 10:47, p...@codeaurora.org wrote: On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza. Should I be doing in next patch-set series ?
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-17 22:15, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: + driver = pci_find_dpc_service(udev); +#endif #if IS_ENABLED(CONFIG_PCIEAER) - /* Use the aer driver of the component firstly */ - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. Right now, find_xxx_service are in their respective file and exporting it. which makes sense no less than having generic function. If I have to change pci_find_service(, int service_name) then it has to be somewhere in generic file. probably portdrv_core.c either way I am fine but just thinking out if its really required. Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-17 22:15, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: + driver = pci_find_dpc_service(udev); +#endif #if IS_ENABLED(CONFIG_PCIEAER) - /* Use the aer driver of the component firstly */ - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. Right now, find_xxx_service are in their respective file and exporting it. which makes sense no less than having generic function. If I have to change pci_find_service(, int service_name) then it has to be somewhere in generic file. probably portdrv_core.c either way I am fine but just thinking out if its really required. Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 2018-01-17 22:16, Sinan Kaya wrote: On 1/17/2018 5:37 AM, Oza Pawandeep wrote: +++ b/include/linux/dpc.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ + can you keep this in drivers/pci.h and get rid of this file? I thought about this, but if I keep it in drivers/pci.h, then AER's defines have to be in that as well. (for unification) and then all the dependent files who are using AER_FATAL such as drivers/acpi/apei/ghees.c have to go on including this drivers file which is odd way of doing it. So I am not very sure about thissince AER_FATAL are in aer.h, I have made dpc.h Regards, Oza.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > +++ b/include/linux/dpc.h > @@ -0,0 +1,9 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef _DPC_H_ > +#define _DPC_H_ > + > +#define DPC_FATAL4 > + > +#endif //_DPC_H_ > + can you keep this in drivers/pci.h and get rid of this file? -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > +++ b/include/linux/dpc.h > @@ -0,0 +1,9 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > +#ifndef _DPC_H_ > +#define _DPC_H_ > + > +#define DPC_FATAL4 > + > +#endif //_DPC_H_ > + can you keep this in drivers/pci.h and get rid of this file? -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > + driver = pci_find_dpc_service(udev); > +#endif > #if IS_ENABLED(CONFIG_PCIEAER) > - /* Use the aer driver of the component firstly */ > - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. -- 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.
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
On 1/17/2018 5:37 AM, Oza Pawandeep wrote: > + driver = pci_find_dpc_service(udev); > +#endif > #if IS_ENABLED(CONFIG_PCIEAER) > - /* Use the aer driver of the component firstly */ > - driver = pci_find_aer_service(udev); I think we need a pci_find_service function that unifies these two. -- 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.
