Address error and recovery for AER and DPC
v5 cover Address error and recovery for AER and DPC
This patch set brings in error handling support for DPC
The current implementation of AER and error message broadcasting to the EP driver is tightly coupled and limited to AER service driver. It is important to factor out broadcasting and other link handling callbacks. So that not only when AER gets triggered, but also when DPC get triggered (for e.g. ERR_FATAL), callbacks are handled appropriately.
DPC should enumerate the devices after recovering the link, which is achieved by implementing error_resume callback.
Changes since v4:
Bjorn's comments incorporated.
> Renamed only do_recovery.
> moved the things more locally to drivers/pci/pci.h
Changes since v3:
Bjorn's comments incorporated.
> Made separate patch renaming generic pci_err.c
> Introduce pci_err.h to contain all the error types and recovery > removed all the dependencies on pci.h
Changes since v2:
Based on feedback from Keith:
"
When DPC is triggered due to receipt of an uncorrectable error Message, the Requester ID from the Message is recorded in the DPC Error Source ID register and that Message is discarded and not forwarded Upstream. "
Removed the patch where AER checks if DPC service is active
Changes since v1:
Kbuild errors fixed:
> pci_find_dpc_dev made static
> ras_event.h updated
> pci_find_aer_service call with CONFIG check
> pci_find_dpc_service call with CONFIG check
Oza Pawandeep (4):
PCI/AER: factor out error reporting from AER PCI/DPC/AER: Address Concurrency between AER and DPC PCI/ERR: Do not do recovery if DPC service is active PCI/DPC: Enumerate the devices after DPC trigger event
drivers/acpi/apei/ghes.c | 2 +- drivers/pci/pcie/Makefile | 2 +- drivers/pci/pcie/aer/aerdrv.h | 30 --- drivers/pci/pcie/aer/aerdrv_core.c | 306 +------------------------ drivers/pci/pcie/aer/aerdrv_errprint.c | 27 ++- drivers/pci/pcie/pcie-dpc.c | 127 ++++++++++- drivers/pci/pcie/pcie-err.c | 399 +++++++++++++++++++++++++++++++++ drivers/pci/pcie/portdrv.h | 2 + include/linux/aer.h | 4 - include/linux/pci.h | 23 ++ include/ras/ras_event.h | 6 +- 11 files changed, 579 insertions(+), 349 deletions(-) create mode 100644 drivers/pci/pcie/pcie-err.c
Signature · 2 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc., a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v5 1/4 PCI/AER: Rename error recovery to generic pci naming
This patch renames error recovery to generic name with pci prefix
drivers/pci/pcie/aer/aerdrv_core.c +4 -4
@@ -482,7 +482,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev) }/** -* do_recovery - handle nonfatal/fatal error recovery process +* pci_do_recovery - handle nonfatal/fatal error recovery process * @dev: pointer to a pci_dev data structure of agent detecting an error * @severity: error severity type *
@@ -490,7 +490,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev)* error detected message to all downstream drivers within a hierarchy in * question and return the returned code. */ -static void do_recovery (struct pci_dev *dev,int severity) +static void pci_do_recovery (struct pci_dev *dev,int severity) {pci_ers_result_t status, result =PCI_ERS_RESULT_RECOVERED ;enum pci_channel_state state;
@@ -569,7 +569,7 @@ static void handle_error_source(struct pcie_device *aerdev,pci_write_config_dword (dev, pos +PCI_ERR_COR_STATUS , info->status); }else -do_recovery (dev, info->severity); +pci_do_recovery (dev, info->severity); }#ifdef CONFIG_ACPI_APEI_PCIEAER
@@ -633,7 +633,7 @@ static void aer_recover_work_func(struct work_struct *work)continue ; }cper_print_aer (pdev, entry.severity, entry.regs); -do_recovery (pdev, entry.severity); +pci_do_recovery (pdev, entry.severity);pci_dev_put (pdev); } }
Signature · 2 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc., a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v5 2/4 PCI/AER: factor out error reporting from AER
In reply to Oza PawandeepThis patch factors out error reporting callbacks, which are currently tightly coupled with AER.
DPC should be able to register callbacks and attmept recovery when DPC trigger event occurs.
drivers/pci/pci.h +3 -0
@@ -342,6 +342,9 @@ static inline resource_size_t pci_resource_alignment(struct pci_dev *dev,void pci_enable_acs (struct pci_dev *dev); +/* PCI error reporting and recovery */ +void pci_do_recovery (struct pci_dev *dev,int severity); +#ifdef CONFIG_PCIE_PTM void pci_ptm_init (struct pci_dev *dev);#else
drivers/pci/pcie/Makefile +1 -1
@@ -6,7 +6,7 @@ # Build PCI Express ASPM if needed obj-$(CONFIG_PCIEASPM) += aspm.o -pcieportdrv-y := portdrv_core.o portdrv_pci.o portdrv_bus.o +pcieportdrv-y := portdrv_core.o portdrv_pci.o portdrv_bus.o pcie-err.o pcieportdrv-$(CONFIG_ACPI) += portdrv_acpi.o obj-$(CONFIG_PCIEPORTBUS) += pcieportdrv.o
drivers/pci/pcie/aer/aerdrv.h +0 -30
@@ -76,36 +76,6 @@ struct aer_rpc {*/ }; -struct aer_broadcast_data { -enum pci_channel_state state; -enum pci_ers_result result; -}; - -static inline pci_ers_result_t merge_result (enum pci_ers_result orig, -enum pci_ers_result new) -{ -if (new ==PCI_ERS_RESULT_NO_AER_DRIVER ) -return PCI_ERS_RESULT_NO_AER_DRIVER ; - -if (new ==PCI_ERS_RESULT_NONE ) -return orig; - -switch (orig) { -case PCI_ERS_RESULT_CAN_RECOVER : -case PCI_ERS_RESULT_RECOVERED : - orig = new; -break ; -case PCI_ERS_RESULT_DISCONNECT : -if (new ==PCI_ERS_RESULT_NEED_RESET ) - orig =PCI_ERS_RESULT_NEED_RESET ; -break ; -default : -break ; - } - -return orig; -} -extern struct bus_type pcie_port_bus_type;void aer_isr (struct work_struct *work);void aer_print_error (struct pci_dev *dev,struct aer_err_info *info);
drivers/pci/pcie/aer/aerdrv_core.c +3 -286
313 lines not on this page · raw message
drivers/pci/pcie/pcie-err.c new file +334 -0
334 lines not on this page · raw message
drivers/pci/pcie/portdrv.h +1 -0
@@ -79,4 +79,5 @@ static inline void pcie_port_platform_notify(struct pci_dev *port, int *mask)static inline void pcie_port_platform_notify (struct pci_dev *port,int *mask){}#endif /* !CONFIG_ACPI */ +struct pcie_port_service_driver *pci_find_aer_service (struct pci_dev *dev);#endif /* _PORTDRV_H_ */
include/linux/aer.h +3 -3
@@ -11,9 +11,9 @@#include <linux/errno.h> #include <linux/types.h> -#define AER_NONFATAL 0 -#define AER_FATAL 1 -#define AER_CORRECTABLE 2 +#define AER_NONFATAL 0 +#define AER_FATAL 1 +#define AER_CORRECTABLE 2struct pci_dev ;
Signature · 2 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc., a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
PATCH v5 3/4 PCI/DPC: Unify and plumb error handling into DPC
In reply to Oza PawandeepCurrent DPC driver does not do recovery, e.g. calling end-point's driver's callbacks, which sanitize the sw.
DPC driver implements link_reset callback, and calls pci_do_recovery.
drivers/pci/pcie/pcie-dpc.c +86 -4
@@ -13,8 +13,12 @@#include <linux/interrupt.h> #include <linux/init.h> #include <linux/pci.h> +#include <linux/dpc.h> #include <linux/pcieport_if.h> #include "../pci.h" +#include "portdrv.h" + +static pci_ers_result_t dpc_reset_link (struct pci_dev *pdev);struct rp_pio_header_log_regs {u32 dw0;
@@ -67,6 +71,60 @@ struct dpc_dev { "Memory Request Completion Timeout", /* Bit Position 18 */ }; +static int find_dpc_dev_iter (struct device *device,void *data) +{ +struct pcie_port_service_driver *service_driver; +struct device **dev; + + dev = (struct device **) data; + +if (device->bus == &pcie_port_bus_type && device->driver) { + service_driver =to_service_driver (device->driver); +if (service_driver->service ==PCIE_PORT_SERVICE_DPC ) { + *dev = device; +return 1 ; + } + } + +return 0 ; +} + +static struct device *pci_find_dpc_dev (struct pci_dev *pdev) +{ +struct device *dev =NULL ; + +device_for_each_child (&pdev->dev, &dev, find_dpc_dev_iter); + +return dev; +} + +static int find_dpc_service_iter (struct device *device,void *data) +{ +struct pcie_port_service_driver *service_driver, **drv; + + drv = (struct pcie_port_service_driver **) data; + +if (device->bus == &pcie_port_bus_type && device->driver) { + service_driver =to_service_driver (device->driver); +if (service_driver->service ==PCIE_PORT_SERVICE_DPC ) { + *drv = service_driver; +return 1 ; + } + } + +return 0 ; +} + +struct pcie_port_service_driver *pci_find_dpc_service (struct pci_dev *dev) +{ +struct pcie_port_service_driver *drv =NULL ; + +device_for_each_child (&dev->dev, &drv, find_dpc_service_iter); + +return drv; +} +EXPORT_SYMBOL (pci_find_dpc_service); +static int dpc_wait_rp_inactive (struct dpc_dev *dpc) {unsigned long timeout = jiffies +HZ ;
@@ -104,11 +162,23 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)dev_warn (dev,"Link state not disabled for DPC event\n" ); } -static void interrupt_event_handler (struct work_struct *work) +/** +* dpc_reset_link - reset link DPC routine +* @dev: pointer to Root Port's pci_dev data structure +* +* Invoked by Port Bus driver when performing link reset at Root Port. +*/ +static pci_ers_result_t dpc_reset_link (struct pci_dev *pdev) { - struct dpc_dev *dpc = container_of(work, struct dpc_dev, work); -struct pci_dev *dev, *temp, *pdev = dpc->dev->port;struct pci_bus *parent = pdev->subordinate; +struct pci_dev *dev, *temp; +struct dpc_dev *dpc; +struct pcie_device *pciedev; +struct device *devdpc; + + devdpc =pci_find_dpc_dev (pdev); + pciedev =to_pcie_device (devdpc); + dpc =get_service_data (pciedev);pci_lock_rescan_remove (); list_for_each_entry_safe_reverse(dev, temp, &parent->devices,
@@ -125,7 +195,7 @@ static void interrupt_event_handler(struct work_struct *work)dpc_wait_link_inactive (dpc);if (dpc->rp &&dpc_wait_rp_inactive (dpc)) -return ; +return PCI_ERS_RESULT_DISCONNECT ;if (dpc->rp && dpc->rp_pio_status) { pci_write_config_dword(pdev, dpc->cap_pos + PCI_EXP_DPC_RP_PIO_STATUS,
@@ -135,6 +205,17 @@ static void interrupt_event_handler(struct work_struct *work)pci_write_config_word (pdev, dpc->cap_pos +PCI_EXP_DPC_STATUS ,PCI_EXP_DPC_STATUS_TRIGGER |PCI_EXP_DPC_STATUS_INTERRUPT ); + +return PCI_ERS_RESULT_RECOVERED ; +} + +static void interrupt_event_handler (struct work_struct *work) +{ + struct dpc_dev *dpc = container_of(work, struct dpc_dev, work); +struct pci_dev *pdev = dpc->dev->port; + +/* From DPC point of view error is always FATAL. */ +pci_do_recovery (pdev,DPC_FATAL ); } static void dpc_rp_pio_print_tlp_header(struct device *dev,
@@ -339,6 +420,7 @@ static void dpc_remove(struct pcie_device *dev) .service = PCIE_PORT_SERVICE_DPC, .probe = dpc_probe, .remove = dpc_remove, + .reset_link = dpc_reset_link, };static int __init dpc_service_init (void )
drivers/pci/pcie/pcie-err.c +23 -6
@@ -17,9 +17,12 @@#include <linux/kernel.h> #include <linux/errno.h> #include <linux/aer.h> +#include <linux/dpc.h> #include <linux/pcieport_if.h> #include "portdrv.h" +static DEFINE_MUTEX (pci_err_recovery_lock); +struct aer_broadcast_data {enum pci_channel_state state;enum pci_ers_result result;
@@ -179,7 +182,7 @@ static pci_ers_result_t default_reset_link(struct pci_dev *dev)return PCI_ERS_RESULT_RECOVERED ; } -static pci_ers_result_t reset_link (struct pci_dev *dev) +static pci_ers_result_t reset_link (struct pci_dev *dev,int severity) {struct pci_dev *udev;pci_ers_result_t status;
@@ -193,9 +196,17 @@ static pci_ers_result_t reset_link(struct pci_dev *dev) udev = dev->bus->self; } + +/* Use the service driver of the component firstly */ +#if IS_ENABLED (CONFIG_PCIE_DPC ) +if (severity ==DPC_FATAL ) + 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); +if ((severity ==AER_FATAL ) || + (severity ==AER_NONFATAL ) || + (severity ==AER_CORRECTABLE )) + driver =pci_find_aer_service (udev);#endif if (driver && driver->reset_link) {
@@ -283,7 +294,10 @@ void pci_do_recovery(struct pci_dev *dev, int severity)pci_ers_result_t status, result =PCI_ERS_RESULT_RECOVERED ;enum pci_channel_state state; -if (severity ==AER_FATAL ) +mutex_lock (&pci_err_recovery_lock); + +if ((severity ==AER_FATAL ) || + (severity ==DPC_FATAL )) state = pci_channel_io_frozen;else state = pci_channel_io_normal;
@@ -293,8 +307,9 @@ void pci_do_recovery(struct pci_dev *dev, int severity)"error_detected" , report_error_detected); -if (severity ==AER_FATAL ) { - result =reset_link (dev); +if ((severity ==AER_FATAL ) || + (severity ==DPC_FATAL )) { + result =reset_link (dev, severity);if (result !=PCI_ERS_RESULT_RECOVERED ) goto failed; }
@@ -326,9 +341,11 @@ void pci_do_recovery(struct pci_dev *dev, int severity) report_resume);dev_info (&dev->dev,"Device recovery successful\n" ); +mutex_unlock (&pci_err_recovery_lock);return ; failed:/* TODO: Should kernel panic here? */ +mutex_unlock (&pci_err_recovery_lock);dev_info (&dev->dev,"Device recovery failed\n" ); }
drivers/pci/pcie/portdrv.h +1 -0
@@ -80,4 +80,5 @@ static inline void pcie_port_platform_notify(struct pci_dev *port, int *mask){}#endif /* !CONFIG_ACPI */ struct pcie_port_service_driver *pci_find_aer_service (struct pci_dev *dev); +struct pcie_port_service_driver *pci_find_dpc_service (struct pci_dev *dev);#endif /* _PORTDRV_H_ */
include/linux/dpc.h new file +9 -0
@@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _DPC_H_ +#define _DPC_H_ + +#define DPC_FATAL 4 + +#endif //_DPC_H_ +
Signature · 2 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc., a 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
drivers/pci/pcie/pcie-err.c static pci_ers_result_t reset_link(struct pci_dev *dev) · line 198
Quoted 5 lines · Oza Pawandeep
drivers/pci/pcie/pcie-err.c +2
-2+ 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.
Signature · 3 lines
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
Quoted 8 lines · Sinan Kaya
drivers/pci/pcie/pcie-err.c static pci_ers_result_t reset_link(struct pci_dev *dev) · line 198
Quoted 5 lines · Oza Pawandeep
drivers/pci/pcie/pcie-err.c +2
-2+ 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_servicefunction 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
Quoted 13 lines · On 2018-01-18 10:52, [email protected] wrote:
Quoted 8 lines · Sinan Kaya
drivers/pci/pcie/pcie-err.c static pci_ers_result_t reset_link(struct pci_dev *dev) · line 198
Quoted 5 lines · Oza Pawandeep
drivers/pci/pcie/pcie-err.c +2
-2+ 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_servicefunction that unifies these two.Right now,
find_xxx_serviceare in their respective file and exporting it. which makes sense no less than having generic function.
Quoted 8 lines
If I have to change
pci_find_service(...., int service_name)then it has to be somewhere in generic file.
probablyportdrv_core.ceither 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
In reply to Oza Pawandeepinclude/linux/dpc.h line 9
Quoted 11 lines · Oza Pawandeep
+++
b/include/linux/dpc.hinclude/linux/dpc.h new file +9
-0@@ -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?
Signature · 3 lines
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
Quoted 14 lines · Sinan Kaya
include/linux/dpc.h line 9
Quoted 11 lines · Oza Pawandeep
+++
b/include/linux/dpc.hinclude/linux/dpc.h new file +9
-0@@ -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.hand 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 this....since 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
Quoted 23 lines · On 2018-01-18 10:47, [email protected] wrote:
Quoted 14 lines · Sinan Kaya
include/linux/dpc.h line 9
Quoted 11 lines · Oza Pawandeep
+++
b/include/linux/dpc.hinclude/linux/dpc.h new file +9
-0@@ -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.hand 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_FATALsuch asdrivers/acpi/apei/ghees.c
have to go on including this drivers file which is odd way of doing it.
Quoted 6 lines
So I am not very sure about this....since
AER_FATALare inaer.h, I have madedpc.hRegards,
Oza.
Should I be doing in next patch-set series ?
Re: [PATCH v5 3/4] PCI/DPC: Unify and plumb error handling into DPC
Quoted 24 lines · On 1/18/2018 12:57 AM, [email protected] wrote:
Quoted 23 lines · On 2018-01-18 10:47, [email protected] wrote:
Quoted 14 lines · Sinan Kaya
include/linux/dpc.h line 9
Quoted 11 lines · Oza Pawandeep
+++
b/include/linux/dpc.hinclude/linux/dpc.h new file +9
-0@@ -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.hand 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_FATALsuch asdrivers/acpi/apei/ghees.c
have to go on including this drivers file which is odd way of doing it.
Quoted 9 lines
Quoted 6 lines
So I am not very sure about this....since
AER_FATALare inaer.h, I have madedpc.hRegards,
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.
Signature · 3 lines
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
Quoted 32 lines · Sinan Kaya
Quoted 31 lines · On 1/18/2018 12:57 AM, [email protected] wrote:
Quoted 29 lines · On 2018-01-18 10:47, [email protected] wrote:
Quoted 14 lines · Sinan Kaya
include/linux/dpc.h line 9
Quoted 11 lines · Oza Pawandeep
+++
b/include/linux/dpc.hinclude/linux/dpc.h new file +9
-0@@ -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.hand 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_FATALsuch asdrivers/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 this....since
AER_FATALare inaer.h, I have madedpc.hRegards,
Oza.
Quoted 8 lines
Quoted 2 lines
Should I be doing in next patch-set series ?
I think you would put into
include/linux/pci.honly if there is an external use of constant outside ofdrivers/pcidirectory. Otherwise, you should keep the setting inside one of the header files indrivers/pcidirectory.I don't see any other subsystem caring about
DPC_FATALdefinition.
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
Quoted 7 lines · On 1/18/2018 1:00 PM, [email protected] wrote:
Quoted 5 lines
I think you would put into
include/linux/pci.honly if there is an external use of constant outside ofdrivers/pcidirectory. Otherwise, you should keep the setting inside one of the header files indrivers/pcidirectory.I don't see any other subsystem caring about
DPC_FATALdefinition.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.
Signature · 3 lines
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
Quoted 7 lines · Sinan Kaya
Quoted 6 lines · On 1/18/2018 1:00 PM, [email protected] wrote:
Quoted 5 lines
I think you would put into
include/linux/pci.honly if there is an external use of constant outside ofdrivers/pcidirectory. Otherwise, you should keep the setting inside one of the header files indrivers/pcidirectory.I don't see any other subsystem caring about
DPC_FATALdefinition.
Quoted 8 lines
Quoted 1 line
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.hrather than having them split inaer.handdpc.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
Quoted 14 lines · On 1/18/2018 11:23 PM, [email protected] wrote:
Quoted 13 lines · Sinan Kaya
Quoted 7 lines · On 1/18/2018 1:00 PM, [email protected] wrote:
Quoted 5 lines
I think you would put into
include/linux/pci.honly if there is an external use of constant outside ofdrivers/pcidirectory. Otherwise, you should keep the setting inside one of the header files indrivers/pcidirectory.I don't see any other subsystem caring about
DPC_FATALdefinition.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.hrather than having them split inaer.handdpc.h.
Quoted 5 lines
Quoted 2 lines
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.chas 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.
Quoted 2 lines
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.
Quoted 4 lines
Regards,
Oza.
Signature · 3 lines
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
Quoted 21 lines · Sinan Kaya
Quoted 14 lines · On 1/18/2018 11:23 PM, [email protected] wrote:
Quoted 13 lines · Sinan Kaya
Quoted 7 lines · On 1/18/2018 1:00 PM, [email protected] wrote:
Quoted 5 lines
I think you would put into
include/linux/pci.honly if there is an external use of constant outside ofdrivers/pcidirectory. Otherwise, you should keep the setting inside one of the header files indrivers/pcidirectory.I don't see any other subsystem caring about
DPC_FATALdefinition.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.hrather than having them split inaer.handdpc.h.Quoted 5 lines
Quoted 2 lines
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.chas to do #include../../pci/pci.h
Quoted 8 lines
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.Quoted 2 lines
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.hand 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.
Quoted 4 lines
Quoted 4 lines
Regards,
Oza.
PATCH v5 4/4 PCI/DPC: Enumerate the devices after DPC trigger event
In reply to Oza PawandeepImplement error_resume callback in DPC so, after DPC trigger event enumerates the devices beneath.
drivers/pci/pcie/pcie-dpc.c +38 -0
@@ -162,6 +162,43 @@ static void dpc_wait_link_inactive(struct dpc_dev *dpc)dev_warn (dev,"Link state not disabled for DPC event\n" ); } +static bool dpc_wait_link_active (struct pci_dev *pdev) +{ +unsigned long timeout = jiffies +HZ ; +u16 lnk_status; +bool ret = true; + +pcie_capability_read_word (pdev,PCI_EXP_LNKSTA , &lnk_status); + +while (!(lnk_status &PCI_EXP_LNKSTA_DLLLA ) && + !time_after (jiffies, timeout)) { +msleep (10 ); +pcie_capability_read_word (pdev,PCI_EXP_LNKSTA , &lnk_status); + } + +if (!(lnk_status &PCI_EXP_LNKSTA_DLLLA )) { +dev_warn (&pdev->dev,"Link state not enabled after DPC event\n" ); + ret = false; + } + +return ret; +} + +/** +* dpc_error_resume - enumerate the devices beneath +* @dev: pointer to Root Port's pci_dev data structure +* +* Invoked by Port Bus driver during nonfatal recovery. +*/ +static void dpc_error_resume (struct pci_dev *pdev) +{ +if (dpc_wait_link_active (pdev)) { +pci_lock_rescan_remove (); +pci_rescan_bus (pdev->bus); +pci_unlock_rescan_remove (); + } +} +/** * dpc_reset_link - reset link DPC routine * @dev: pointer to Root Port's pci_dev data structure
@@ -420,6 +457,7 @@ static void dpc_remove(struct pcie_device *dev) .service = PCIE_PORT_SERVICE_DPC, .probe = dpc_probe, .remove = dpc_remove, + .error_resume = dpc_error_resume, .reset_link = dpc_reset_link, };
drivers/pci/pcie/pcie-err.c +20 -5
@@ -236,6 +236,7 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int severity)* @state: error state * @error_mesg: message to print * @cb: callback to be broadcasted +* @severity: error severity * * Invoked during error recovery process. Once being invoked, the content * of error severity will be broadcasted to all downstream drivers in a
@@ -244,7 +245,8 @@ static pci_ers_result_t reset_link(struct pci_dev *dev, int severity)static pci_ers_result_t broadcast_error_message (struct pci_dev *dev,enum pci_channel_state state,char *error_mesg, -int (*cb)(struct pci_dev *,void *)) +int (*cb)(struct pci_dev *,void *), +int severity) {struct aer_broadcast_data result_data;
@@ -256,6 +258,15 @@ static pci_ers_result_t broadcast_error_message(struct pci_dev *dev, result_data.result =PCI_ERS_RESULT_RECOVERED ;if (dev->hdr_type ==PCI_HEADER_TYPE_BRIDGE ) { +/* If DPC is triggered, call resume error hanlder +* because, at this point we can safely assume that +* link recovery has happened. +*/ +if ((severity ==DPC_FATAL ) && + (cb == report_resume)) { +cb (dev,NULL ); +return PCI_ERS_RESULT_RECOVERED ; + }/* * If the error is reported by a bridge, we think this error * is related to the downstream link of the bridge, so we
@@ -305,7 +316,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity) status =broadcast_error_message (dev, state,"error_detected" , - report_error_detected); + report_error_detected, + severity);if ((severity ==AER_FATAL ) || (severity ==DPC_FATAL )) {
@@ -318,7 +330,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity) status =broadcast_error_message (dev, state,"mmio_enabled" , - report_mmio_enabled); + report_mmio_enabled, + severity);if (status ==PCI_ERS_RESULT_NEED_RESET ) {/*
@@ -329,7 +342,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity) status =broadcast_error_message (dev, state,"slot_reset" , - report_slot_reset); + report_slot_reset, + severity); }if (status !=PCI_ERS_RESULT_RECOVERED )
@@ -338,7 +352,8 @@ void pci_do_recovery(struct pci_dev *dev, int severity)broadcast_error_message (dev, state,"resume" , - report_resume); + report_resume, + severity);dev_info (&dev->dev,"Device recovery successful\n" );mutex_unlock (&pci_err_recovery_lock);
Signature · 2 lines
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc., a Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{
I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
Signature · 3 lines
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 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Quoted 6 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
It is actually very similar to __pcie_wait_link_active in pciehp_hpc.c, so there's some opprotunity to make even more common code.
Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Quoted 10 lines · Keith Busch
Quoted 6 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
It is actually very similar to
__pcie_wait_link_activeinpciehp_hpc.c, so there's some opprotunity to make even more common code.
in that case there has to be a generic function in drives/pci.c
which addresses folowing functions from
pcie-dpc.c:dpc_wait_link_inactivedpc_wait_link_active
drivers/pci/hotplug/pciehp_hpc.cpcie_wait_link_active
all aboe making one generic function to be moved to drives/pci.c
please let me know if this is okay.
Regards,
Oza.
Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Quoted 21 lines · On 1/18/2018 12:32 AM, [email protected] wrote:
Quoted 10 lines · Keith Busch
Quoted 6 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
It is actually very similar to
__pcie_wait_link_activeinpciehp_hpc.c, so there's some opprotunity to make even more common code.in that case there has to be a generic function in
drives/pci.cwhich addresses folowing functions from
pcie-dpc.c:dpc_wait_link_inactivedpc_wait_link_active
Quoted 7 lines
drivers/pci/hotplug/pciehp_hpc.cpcie_wait_link_activeall aboe making one generic function to be moved to
drives/pci.cplease let me know if this is okay.
Works for me. Keith/Bjorn?
Quoted 5 lines
Regards,
Oza.
Signature · 3 lines
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 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Quoted 26 lines · Sinan Kaya
Quoted 25 lines · On 1/18/2018 12:32 AM, [email protected] wrote:
Quoted 10 lines · Keith Busch
Quoted 6 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
It is actually very similar to
__pcie_wait_link_activeinpciehp_hpc.c, so there's some opprotunity to make even more common code.in that case there has to be a generic function in
drives/pci.cwhich addresses folowing functions from
pcie-dpc.c:dpc_wait_link_inactivedpc_wait_link_active
drivers/pci/hotplug/pciehp_hpc.cpcie_wait_link_active
Quoted 5 lines
Quoted 3 lines
all aboe making one generic function to be moved to
drives/pci.cplease let me know if this is okay.
Works for me. Keith/Bjorn?
Yep, I believe common solutions that reduce code is always encouraged in the Linux kernel.
Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
Quoted 27 lines · Keith Busch
Quoted 26 lines · Sinan Kaya
Quoted 25 lines · On 1/18/2018 12:32 AM, [email protected] wrote:
Quoted 10 lines · Keith Busch
Quoted 6 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here. Of course, this would be another patch.
It is actually very similar to
__pcie_wait_link_activeinpciehp_hpc.c, so there's some opprotunity to make even more common code.in that case there has to be a generic function in
drives/pci.cwhich addresses folowing functions from
pcie-dpc.c:dpc_wait_link_inactivedpc_wait_link_active
drivers/pci/hotplug/pciehp_hpc.cpcie_wait_link_active
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
all aboe making one generic function to be moved to
drives/pci.cplease let me know if this is okay.
Works for me. Keith/Bjorn?
Yep, I believe common solutions that reduce code is always encouraged in the Linux kernel.
okay, I will work on this.
Regards,
Oza.
Re: [PATCH v5 4/4] PCI/DPC: Enumerate the devices after DPC trigger event
In reply to Sinan KayaQuoted 7 lines · Sinan Kaya
Review
Quoted 2 lines · Oza Pawandeep
(quoted diff) +2
-0+static bool dpc_wait_link_active(struct pci_dev *pdev) +{I think you can also make this function common instead of making another copy here.
Of course, this would be another patch.
ok I will make a separate patch taking one more parameter dpc_wait_link_active(struct pci_dev *, bool)
if not in this series, then immediate one.
Regards,
Oza.