Re: [PATCH v2 0/3] PCIe Host request to reserve IOVA

On 2018-12-13 16:02, Srinath Mannam wrote: Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be

Re: [RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host

On 2018-12-13 14:47, Srinath Mannam wrote: Hi Oza, Thank you for the review. Please find my comments in lined. On Thu, Dec 13, 2018 at 11:33 AM wrote: On 2018-12-12 11:16, Srinath Mannam wrote: > IPROC host has the limitation that it can use > only those address ranges given by dma-ranges >

Re: [RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host

On 2018-12-12 11:16, Srinath Mannam wrote: IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. All such reserved addresses are

ASPEED graphics card: ast_pci_probe causes RCU stalls

Hi, we have on-board ASPEED Graphics card on PCIe. kernel version: 4.16 I select following drive to enable ast graphics support. Symbol: DRM_AST [=y]

ASPEED graphics card: ast_pci_probe causes RCU stalls

Hi, we have on-board ASPEED Graphics card on PCIe. kernel version: 4.16 I select following drive to enable ast graphics support. Symbol: DRM_AST [=y]

Re: [PATCH] PCI/AER: Clear uncorrectable error status for device

On 2018-09-27 03:38, Bjorn Helgaas wrote: [+cc Sinan, LKML] On Tue, Sep 18, 2018 at 04:20:29AM -0400, Oza Pawandeep wrote: PCI based device drivers handles ERR_NONFATAL by registering pci_error_handlers. some of the drivers clear AER uncorrectable status in slot_reset while some in resume.

Re: [PATCH] PCI/AER: Clear uncorrectable error status for device

On 2018-09-27 03:38, Bjorn Helgaas wrote: [+cc Sinan, LKML] On Tue, Sep 18, 2018 at 04:20:29AM -0400, Oza Pawandeep wrote: PCI based device drivers handles ERR_NONFATAL by registering pci_error_handlers. some of the drivers clear AER uncorrectable status in slot_reset while some in resume.

Re: [PATCH] PCI/AER: Clear uncorrectable error status for device

On 2018-09-18 20:00, Sinan Kaya wrote: On 9/18/2018 4:20 AM, Oza Pawandeep wrote: +++ b/drivers/pci/pcie/err.c @@ -265,6 +265,8 @@ static pci_ers_result_t broadcast_error_message(struct pci_dev *dev, * The error is non fatal so the bus is ok; just invoke *

Re: [PATCH] PCI/AER: Clear uncorrectable error status for device

On 2018-09-18 20:00, Sinan Kaya wrote: On 9/18/2018 4:20 AM, Oza Pawandeep wrote: +++ b/drivers/pci/pcie/err.c @@ -265,6 +265,8 @@ static pci_ers_result_t broadcast_error_message(struct pci_dev *dev, * The error is non fatal so the bus is ok; just invoke *

Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-09-06 01:40, Bjorn Helgaas wrote: On Thu, Aug 09, 2018 at 08:41:27PM +0530, p...@codeaurora.org wrote: On 2018-08-09 20:27, Bharat Kumar Gogada wrote: > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages > will be forwarded from the secondary interface to the primary interface, >

Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-09-06 01:40, Bjorn Helgaas wrote: On Thu, Aug 09, 2018 at 08:41:27PM +0530, p...@codeaurora.org wrote: On 2018-08-09 20:27, Bharat Kumar Gogada wrote: > As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages > will be forwarded from the secondary interface to the primary interface, >

Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-09 20:27, Bharat Kumar Gogada wrote: As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be forwarded from the secondary interface to the primary interface, if the SERR# Enable bit in the Bridge Control register is set. Currently PCI_BRIDGE_CTL_SERR is being enabled only

Re: [PATCH v2] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-09 20:27, Bharat Kumar Gogada wrote: As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be forwarded from the secondary interface to the primary interface, if the SERR# Enable bit in the Bridge Control register is set. Currently PCI_BRIDGE_CTL_SERR is being enabled only

Re: [PATCH] PCI/AER: Remove duplicate PCI_EXP_AER_FLAGS definition

On 2018-08-01 04:20, Bjorn Helgaas wrote: From: Bjorn Helgaas PCI_EXP_AER_FLAGS was defined twice (with identical definitions), once under #ifdef CONFIG_ACPI_APEI, and again at the top level. This looks like my merge error from these commits: fd3362cb73de ("PCI/AER: Squash aerdrv_core.c

Re: [PATCH] PCI/AER: Remove duplicate PCI_EXP_AER_FLAGS definition

On 2018-08-01 04:20, Bjorn Helgaas wrote: From: Bjorn Helgaas PCI_EXP_AER_FLAGS was defined twice (with identical definitions), once under #ifdef CONFIG_ACPI_APEI, and again at the top level. This looks like my merge error from these commits: fd3362cb73de ("PCI/AER: Squash aerdrv_core.c

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-02 11:53, p...@codeaurora.org wrote: On 2018-08-01 04:17, Bjorn Helgaas wrote: On Thu, Jul 12, 2018 at 08:15:19PM +0530, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-02 11:53, p...@codeaurora.org wrote: On 2018-08-01 04:17, Bjorn Helgaas wrote: On Thu, Jul 12, 2018 at 08:15:19PM +0530, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-01 04:17, Bjorn Helgaas wrote: On Thu, Jul 12, 2018 at 08:15:19PM +0530, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to upstream device. This patch enables SERR# for

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-08-01 04:17, Bjorn Helgaas wrote: On Thu, Jul 12, 2018 at 08:15:19PM +0530, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to upstream device. This patch enables SERR# for

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-21 11:37, Sinan Kaya wrote: On 7/20/2018 7:58 PM, Sinan Kaya wrote: We need to figure out how to gracefully return inside hotplug driver if link down happened and there is an error pending. How about adding the following into the hotplug ISR? 1. check if firmware first is disabled

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-21 11:37, Sinan Kaya wrote: On 7/20/2018 7:58 PM, Sinan Kaya wrote: We need to figure out how to gracefully return inside hotplug driver if link down happened and there is an error pending. How about adding the following into the hotplug ISR? 1. check if firmware first is disabled

[RFC] SERR# handling by Linux

Hi Bjorn and Keith, This discussion is to extend the idea of follwing patch. [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow PCIe Spec 7.6.2.1.3 Command Register (Offset 04h) SERR# Enable – See Section 7.6.2.1.14. When Set, this bit enables reporting upstream of Non-fatal and Fatal

[RFC] SERR# handling by Linux

Hi Bjorn and Keith, This discussion is to extend the idea of follwing patch. [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow PCIe Spec 7.6.2.1.3 Command Register (Offset 04h) SERR# Enable – See Section 7.6.2.1.14. When Set, this bit enables reporting upstream of Non-fatal and Fatal

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-18 19:04, Bharat Kumar Gogada wrote: On 2018-07-13 19:25, Bharat Kumar Gogada wrote: >> > Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. >> > This bit is required for forwarding errors reported by EP devices >> > to upstream device. >> > This patch enables SERR# for

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-18 19:04, Bharat Kumar Gogada wrote: On 2018-07-13 19:25, Bharat Kumar Gogada wrote: >> > Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. >> > This bit is required for forwarding errors reported by EP devices >> > to upstream device. >> > This patch enables SERR# for

Re: [PATCH v3 0/7] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

On 2018-07-19 01:14, Bjorn Helgaas wrote: This is a v3 of Oza's patches [1]. It's available at [2] if you prefer git. v3 changes: - Add pci_aer_clear_fatal_status() to clear ERR_FATAL bits, only called from pcie_do_fatal_recovery(). Moved to first in series to avoid a window where

Re: [PATCH v3 0/7] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

On 2018-07-19 01:14, Bjorn Helgaas wrote: This is a v3 of Oza's patches [1]. It's available at [2] if you prefer git. v3 changes: - Add pci_aer_clear_fatal_status() to clear ERR_FATAL bits, only called from pcie_do_fatal_recovery(). Moved to first in series to avoid a window where

Re: [PATCH v3 0/7] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

On 2018-07-19 01:14, Bjorn Helgaas wrote: This is a v3 of Oza's patches [1]. It's available at [2] if you prefer git. v3 changes: - Add pci_aer_clear_fatal_status() to clear ERR_FATAL bits, only called from pcie_do_fatal_recovery(). Moved to first in series to avoid a window where

Re: [PATCH v3 0/7] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

On 2018-07-19 01:14, Bjorn Helgaas wrote: This is a v3 of Oza's patches [1]. It's available at [2] if you prefer git. v3 changes: - Add pci_aer_clear_fatal_status() to clear ERR_FATAL bits, only called from pcie_do_fatal_recovery(). Moved to first in series to avoid a window where

Re: [PATCH v2 1/6] PCI/AER: Take severity mask into account while clearing error bits

On 2018-07-18 03:06, Bjorn Helgaas wrote: On Tue, Jul 17, 2018 at 02:03:29PM -0500, Bjorn Helgaas wrote: Hi Oza, Thanks for doing this! On Fri, Jun 22, 2018 at 05:58:09AM -0400, Oza Pawandeep wrote: > pci_cleanup_aer_uncorrect_error_status() is called by different slot_reset > callbacks in

Re: [PATCH v2 1/6] PCI/AER: Take severity mask into account while clearing error bits

On 2018-07-18 03:06, Bjorn Helgaas wrote: On Tue, Jul 17, 2018 at 02:03:29PM -0500, Bjorn Helgaas wrote: Hi Oza, Thanks for doing this! On Fri, Jun 22, 2018 at 05:58:09AM -0400, Oza Pawandeep wrote: > pci_cleanup_aer_uncorrect_error_status() is called by different slot_reset > callbacks in

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-13 19:25, Bharat Kumar Gogada wrote: > Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. > This bit is required for forwarding errors reported by EP devices to > upstream device. > This patch enables SERR# for Type-1 PCI device. > > Signed-off-by: Bharat Kumar Gogada

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-13 19:25, Bharat Kumar Gogada wrote: > Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. > This bit is required for forwarding errors reported by EP devices to > upstream device. > This patch enables SERR# for Type-1 PCI device. > > Signed-off-by: Bharat Kumar Gogada

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-12 20:15, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to upstream device. This patch enables SERR# for Type-1 PCI device. Signed-off-by: Bharat Kumar Gogada ---

Re: [PATCH] PCI/AER: Enable SERR# forwarding in non ACPI flow

On 2018-07-12 20:15, Bharat Kumar Gogada wrote: Currently PCI_BRIDGE_CTL_SERR is being enabled only in ACPI flow. This bit is required for forwarding errors reported by EP devices to upstream device. This patch enables SERR# for Type-1 PCI device. Signed-off-by: Bharat Kumar Gogada ---

Re: [PATCH v2 0/6] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

Hi Bjorn, Could you help to review this series ? Regards, Oza. On 2018-06-22 15:28, Oza Pawandeep wrote: These are follow up patches for the series which modifies ERR_FATAL handling. although there were couple of problems existed before which, itis also fixing. patch-1: Fixes the problem

Re: [PATCH v2 0/6] Fix issues and cleanup for ERR_FATAL and ERR_NONFATAL

Hi Bjorn, Could you help to review this series ? Regards, Oza. On 2018-06-22 15:28, Oza Pawandeep wrote: These are follow up patches for the series which modifies ERR_FATAL handling. although there were couple of problems existed before which, itis also fixing. patch-1: Fixes the problem

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 20:04, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: @@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32 service) pci_dev_put(pdev); } + hpsvc = pcie_port_find_service(udev,

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 20:04, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: @@ -308,8 +310,17 @@ void pcie_do_fatal_recovery(struct pci_dev *dev, u32 service) pci_dev_put(pdev); } + hpsvc = pcie_port_find_service(udev,

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 19:42, Lukas Wunner wrote: On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote: On 2018-07-03 04:34, Lukas Wunner wrote: >On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: >>If a bridge supports hotplug and observes a PCIe fatal error, the >>following

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 19:42, Lukas Wunner wrote: On Tue, Jul 03, 2018 at 07:30:28AM -0400, ok...@codeaurora.org wrote: On 2018-07-03 04:34, Lukas Wunner wrote: >On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: >>If a bridge supports hotplug and observes a PCIe fatal error, the >>following

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 19:29, Lukas Wunner wrote: On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote: Issue is observing hotplug link down event in the middle of AER recovery as in my previous reply. If we mask hotplug interrupts before secondary bus reset via my patch, then hotplug driver

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 19:29, Lukas Wunner wrote: On Tue, Jul 03, 2018 at 09:31:24AM -0400, Sinan Kaya wrote: Issue is observing hotplug link down event in the middle of AER recovery as in my previous reply. If we mask hotplug interrupts before secondary bus reset via my patch, then hotplug driver

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 17:00, ok...@codeaurora.org wrote: On 2018-07-03 04:34, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: If a bridge supports hotplug and observes a PCIe fatal error, the following events happen: 1. AER driver removes the devices from PCI tree on

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 17:00, ok...@codeaurora.org wrote: On 2018-07-03 04:34, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: If a bridge supports hotplug and observes a PCIe fatal error, the following events happen: 1. AER driver removes the devices from PCI tree on

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 14:04, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: If a bridge supports hotplug and observes a PCIe fatal error, the following events happen: 1. AER driver removes the devices from PCI tree on fatal error 2. AER driver brings down the link by

Re: [PATCH V5 3/3] PCI: Mask and unmask hotplug interrupts during reset

On 2018-07-03 14:04, Lukas Wunner wrote: On Mon, Jul 02, 2018 at 06:52:47PM -0400, Sinan Kaya wrote: If a bridge supports hotplug and observes a PCIe fatal error, the following events happen: 1. AER driver removes the devices from PCI tree on fatal error 2. AER driver brings down the link by

Re: [PATCH] PCI/AER: Adopt lspci naming convention for AER prints

On 2018-06-26 21:14, Tyler Baicar wrote: lspci uses abbreviated naming for AER error strings. Adopt the same naming convention for the AER printing so they match. Signed-off-by: Tyler Baicar --- drivers/pci/pcie/aer.c | 46 +++--- 1 file changed, 23

Re: [PATCH] PCI/AER: Adopt lspci naming convention for AER prints

On 2018-06-26 21:14, Tyler Baicar wrote: lspci uses abbreviated naming for AER error strings. Adopt the same naming convention for the AER printing so they match. Signed-off-by: Tyler Baicar --- drivers/pci/pcie/aer.c | 46 +++--- 1 file changed, 23

Re: [PATCH v2 3/5] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-06-12 22:28, Ray Jui wrote: On 6/12/2018 1:29 AM, p...@codeaurora.org wrote: On 2018-06-12 05:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled

Re: [PATCH v2 3/5] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-06-12 22:28, Ray Jui wrote: On 6/12/2018 1:29 AM, p...@codeaurora.org wrote: On 2018-06-12 05:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled

Re: [PATCH v2 2/5] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-06-12 13:57, p...@codeaurora.org wrote: On 2018-06-12 05:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the

Re: [PATCH v2 2/5] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-06-12 13:57, p...@codeaurora.org wrote: On 2018-06-12 05:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the

Re: [PATCH 2/6] PCI: iproc: Add INTx support with better modeling

On 2018-05-30 03:28, Ray Jui wrote: Add PCIe legacy interrupt INTx support to the iProc PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC, INTD share the same interrupt line connected to the GIC in the system, while the status of each INTx can be obtained

Re: [PATCH 2/6] PCI: iproc: Add INTx support with better modeling

On 2018-05-30 03:28, Ray Jui wrote: Add PCIe legacy interrupt INTx support to the iProc PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC, INTD share the same interrupt line connected to the GIC in the system, while the status of each INTx can be obtained

Re: [PATCH v2 5/5] PCI: iproc: Reduce inbound/outbound mapping print level

On 2018-06-12 05:51, Ray Jui wrote: Reduce inbound/outbound mapping print level from dev_info to dev_dbg. This reduces the console logs during Linux boot process Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- drivers/pci/host/pcie-iproc.c | 34 +- 1

Re: [PATCH v2 5/5] PCI: iproc: Reduce inbound/outbound mapping print level

On 2018-06-12 05:51, Ray Jui wrote: Reduce inbound/outbound mapping print level from dev_info to dev_dbg. This reduces the console logs during Linux boot process Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- drivers/pci/host/pcie-iproc.c | 34 +- 1

Re: [PATCH v2 1/5] PCI: iproc: Activate PAXC bridge quirk for more devices

On 2018-06-12 05:51, Ray Jui wrote: Activate PAXC bridge quirk for more PAXC based PCIe root complex with the following PCIe device ID: 0xd750, 0xd802, 0xd804 Signed-off-by: Ray Jui --- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/quirks.c

Re: [PATCH v2 1/5] PCI: iproc: Activate PAXC bridge quirk for more devices

On 2018-06-12 05:51, Ray Jui wrote: Activate PAXC bridge quirk for more PAXC based PCIe root complex with the following PCIe device ID: 0xd750, 0xd802, 0xd804 Signed-off-by: Ray Jui --- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/quirks.c

Re: [PATCH v2 4/5] PCI: iproc: Reject unconfigured physical functions from PAXC

On 2018-06-12 05:51, Ray Jui wrote: PAXC is an emulated PCIe root complex internally in various Broadcom based SoCs. PAXC internally connects to the embedded network processor within these SoCs, with the embedeed network processor exposed as an endpoint device The number of physical functions

Re: [PATCH v2 4/5] PCI: iproc: Reject unconfigured physical functions from PAXC

On 2018-06-12 05:51, Ray Jui wrote: PAXC is an emulated PCIe root complex internally in various Broadcom based SoCs. PAXC internally connects to the embedded network processor within these SoCs, with the embedeed network processor exposed as an endpoint device The number of physical functions

Re: [PATCH v2 3/5] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-06-12 05:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- drivers/pci/host/pcie-iproc.c | 34

Re: [PATCH v2 3/5] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-06-12 05:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- drivers/pci/host/pcie-iproc.c | 34

Re: [PATCH v2 2/5] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-06-12 05:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the capability registers completely and therefore the root

Re: [PATCH v2 2/5] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-06-12 05:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the capability registers completely and therefore the root

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-11 15:31, p...@codeaurora.org wrote: On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-11 15:31, p...@codeaurora.org wrote: On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [RFC PATCH v1 0/9] PCI/portdrv: Squash into one file

On 2018-06-09 01:42, Bjorn Helgaas wrote: The portdrv code is scattered across several files, which makes it a bit of a hassle to browse. Consolidate it all in a single file. Although I do not have any objection is merging the code, It looks to me that the 2 files served purpose of keeping

Re: [RFC PATCH v1 0/9] PCI/portdrv: Squash into one file

On 2018-06-09 01:42, Bjorn Helgaas wrote: The portdrv code is scattered across several files, which makes it a bit of a hassle to browse. Consolidate it all in a single file. Although I do not have any objection is merging the code, It looks to me that the 2 files served purpose of keeping

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-08 03:04, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote: On 2018-06-07 11:30, Oza Pawandeep wrote: > We are handling ERR_FATAL by resetting the Link in software,skipping the > driver pci_error_handlers callbacks, removing the devices from

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-07 11:30, Oza Pawandeep wrote: We are handling ERR_FATAL by resetting the Link in software,skipping the driver pci_error_handlers callbacks, removing the devices from the PCI subsystem, and re-enumerating, as a result of that, no more calling pcie_portdrv_slot_reset in ERR_FATAL

Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()

On 2018-06-07 11:30, Oza Pawandeep wrote: We are handling ERR_FATAL by resetting the Link in software,skipping the driver pci_error_handlers callbacks, removing the devices from the PCI subsystem, and re-enumerating, as a result of that, no more calling pcie_portdrv_slot_reset in ERR_FATAL

Re: [PATCH NEXT 1/6] PCI/AER: Take mask into account while clearing error bits

On 2018-06-07 18:51, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 02:00:29AM -0400, Oza Pawandeep wrote: PCIe ERR_NONFATAL and ERR_FATAL are uncorrectable errors, and clearing uncorrectable error bits should take error mask into account. Signed-off-by: Oza Pawandeep If/when you repost

Re: [PATCH NEXT 1/6] PCI/AER: Take mask into account while clearing error bits

On 2018-06-07 18:51, Bjorn Helgaas wrote: On Thu, Jun 07, 2018 at 02:00:29AM -0400, Oza Pawandeep wrote: PCIe ERR_NONFATAL and ERR_FATAL are uncorrectable errors, and clearing uncorrectable error bits should take error mask into account. Signed-off-by: Oza Pawandeep If/when you repost

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-05-17 22:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled Signed-off-by: Ray Jui Reviewed-by: Scott Branden

Re: [PATCH INTERNAL 3/3] PCI: iproc: Disable MSI parsing in certain PAXC blocks

On 2018-05-17 22:51, Ray Jui wrote: The internal MSI parsing logic in certain revisions of PAXC root complexes does not work properly and can casue corruptions on the writes. They need to be disabled Signed-off-by: Ray Jui Reviewed-by: Scott Branden --- drivers/pci/host/pcie-iproc.c | 34

Re: [PATCH INTERNAL 2/3] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-05-17 22:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the capability registers completely and therefore the root

Re: [PATCH INTERNAL 2/3] PCI: iproc: Fix up corrupted PAXC root complex config registers

On 2018-05-17 22:51, Ray Jui wrote: On certain versions of Broadcom PAXC based root complexes, certain regions of the configuration space are corrupted. As a result, it prevents the Linux PCIe stack from traversing the linked list of the capability registers completely and therefore the root

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 18:34, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote: On 2018-05-16 16:22, Bjorn Helgaas wrote: > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: > > On 2018-05-16 05:26, Bjorn Helgaas wrote: > > > On Fri, May 11,

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 18:34, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote: On 2018-05-16 16:22, Bjorn Helgaas wrote: > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: > > On 2018-05-16 05:26, Bjorn Helgaas wrote: > > > On Fri, May 11,

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 18:34, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote: On 2018-05-16 16:22, Bjorn Helgaas wrote: > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: > > On 2018-05-16 05:26, Bjorn Helgaas wrote: > > > On Fri, May 11,

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 18:34, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 05:45:58PM +0530, p...@codeaurora.org wrote: On 2018-05-16 16:22, Bjorn Helgaas wrote: > On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: > > On 2018-05-16 05:26, Bjorn Helgaas wrote: > > > On Fri, May 11,

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 16:22, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: On 2018-05-16 05:26, Bjorn Helgaas wrote: > On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: > > On 2018-05-11 16:13, Oza Pawandeep wrote: > > > DPC driver

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 16:22, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: On 2018-05-16 05:26, Bjorn Helgaas wrote: > On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: > > On 2018-05-11 16:13, Oza Pawandeep wrote: > > > DPC driver

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 16:22, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: On 2018-05-16 05:26, Bjorn Helgaas wrote: > On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: > > On 2018-05-11 16:13, Oza Pawandeep wrote: > > > DPC driver

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 16:22, Bjorn Helgaas wrote: On Wed, May 16, 2018 at 01:46:25PM +0530, p...@codeaurora.org wrote: On 2018-05-16 05:26, Bjorn Helgaas wrote: > On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: > > On 2018-05-11 16:13, Oza Pawandeep wrote: > > > DPC driver

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 05:26, Bjorn Helgaas wrote: On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: On 2018-05-11 16:13, Oza Pawandeep wrote: > DPC driver implements link_reset callback, and calls > pci_do_fatal_recovery(). > > Which follows standard path of ERR_FATAL recovery. > >

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-16 05:26, Bjorn Helgaas wrote: On Fri, May 11, 2018 at 05:22:08PM +0530, p...@codeaurora.org wrote: On 2018-05-11 16:13, Oza Pawandeep wrote: > DPC driver implements link_reset callback, and calls > pci_do_fatal_recovery(). > > Which follows standard path of ERR_FATAL recovery. > >

Re: [PATCH v16 3/9] PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices

On 2018-05-16 05:29, Bjorn Helgaas wrote: On Fri, May 11, 2018 at 06:43:22AM -0400, Oza Pawandeep wrote: This patch alters the behavior of handling of ERR_FATAL, where removal of devices is initiated, followed by reset link, followed by re-enumeration. So the errors are handled in a different

Re: [PATCH v16 3/9] PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices

On 2018-05-16 05:29, Bjorn Helgaas wrote: On Fri, May 11, 2018 at 06:43:22AM -0400, Oza Pawandeep wrote: This patch alters the behavior of handling of ERR_FATAL, where removal of devices is initiated, followed by reset link, followed by re-enumeration. So the errors are handled in a different

Re: [PATCH v16 5/9] PCI/AER: Factor out error reporting from AER

On 2018-05-11 21:24, Lukas Wunner wrote: On Fri, May 11, 2018 at 09:04:36PM +0530, p...@codeaurora.org wrote: On 2018-05-11 18:28, Lukas Wunner wrote: >On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote: >>+void pcie_do_fatal_recovery(struct pci_dev *dev) >>+{ >>+ struct

Re: [PATCH v16 5/9] PCI/AER: Factor out error reporting from AER

On 2018-05-11 21:24, Lukas Wunner wrote: On Fri, May 11, 2018 at 09:04:36PM +0530, p...@codeaurora.org wrote: On 2018-05-11 18:28, Lukas Wunner wrote: >On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote: >>+void pcie_do_fatal_recovery(struct pci_dev *dev) >>+{ >>+ struct

Re: [PATCH v16 5/9] PCI/AER: Factor out error reporting from AER

On 2018-05-11 18:28, Lukas Wunner wrote: On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote: +void pcie_do_fatal_recovery(struct pci_dev *dev) +{ + struct pci_dev *udev; + struct pci_bus *parent; + struct pci_dev *pdev, *temp; + pci_ers_result_t result =

Re: [PATCH v16 5/9] PCI/AER: Factor out error reporting from AER

On 2018-05-11 18:28, Lukas Wunner wrote: On Fri, May 11, 2018 at 06:43:24AM -0400, Oza Pawandeep wrote: +void pcie_do_fatal_recovery(struct pci_dev *dev) +{ + struct pci_dev *udev; + struct pci_bus *parent; + struct pci_dev *pdev, *temp; + pci_ers_result_t result =

Re: [PATCH v16 8/9] PCI/DPC: Unify and plumb error handling into DPC

On 2018-05-11 16:13, Oza Pawandeep wrote: DPC driver implements link_reset callback, and calls pci_do_fatal_recovery(). Which follows standard path of ERR_FATAL recovery. Signed-off-by: Oza Pawandeep diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index

  1   2   3   >