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 reserve
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
>
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 create
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]
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.
Dr
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
* the
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,
> i
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 in
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 i
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 u
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 Type
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
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
e
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
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
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
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 cas
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
>
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
---
drivers
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 wh
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, PCIE_PORT_SERVICE_HP
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
>>e
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 will
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 f
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 i
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 in
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
Signed-of
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
capability
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 throu
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 file
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 b/drivers/p
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 fr
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
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 comp
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 pci_error_
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 the
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
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 the
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 the
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 case.
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 these,
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
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 comp
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, 2018
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, 2018
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 implement
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 implement
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.
>
> Si
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 w
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 pci_dev
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 = PCI_ER
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 5e8857a..6af7595 100644
--- a/driver
On 2018-05-10 18:52, Bjorn Helgaas wrote:
On Thu, May 03, 2018 at 01:03:57AM -0400, Oza Pawandeep wrote:
Current 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().
Signe
On 2018-05-10 18:45, ok...@codeaurora.org wrote:
On 2018-05-10 14:10, Bjorn Helgaas wrote:
On Thu, May 10, 2018 at 12:31:16PM +0530, p...@codeaurora.org wrote:
On 2018-05-10 04:51, Bjorn Helgaas wrote:
> On Wed, May 09, 2018 at 06:44:53PM +0530, p...@codeaurora.org wrote:
> > On 2018-05-09 18:3
On 2018-05-10 04:51, Bjorn Helgaas wrote:
On Wed, May 09, 2018 at 06:44:53PM +0530, p...@codeaurora.org wrote:
On 2018-05-09 18:37, Bjorn Helgaas wrote:
> On Tue, May 08, 2018 at 06:53:30PM -0500, Bjorn Helgaas wrote:
> > On Thu, May 03, 2018 at 01:03:52AM -0400, Oza Pawandeep wrote:
> > > This
On 2018-05-09 18:37, Bjorn Helgaas wrote:
On Tue, May 08, 2018 at 06:53:30PM -0500, Bjorn Helgaas wrote:
On Thu, May 03, 2018 at 01:03:52AM -0400, Oza Pawandeep wrote:
> This patch alters the behavior of handling of ERR_FATAL, where removal
> of devices is initiated, followed by reset link, foll
On 2018-05-03 10:33, Oza Pawandeep wrote:
This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
DPC should be able to register callbacks and attempt recovery when DPC
trigger event occurs.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/Mak
On 2018-05-01 04:10, Bjorn Helgaas wrote:
On Thu, Apr 26, 2018 at 11:00:52AM +0530, p...@codeaurora.org wrote:
On 2018-04-23 20:53, Oza Pawandeep wrote:
> This patch set brings in error handling support for DPC
>
> The current implementation of AER and error message broadcasting to the
> EP driv
On 2018-04-23 20:53, Oza Pawandeep wrote:
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 hand
On 2018-04-16 20:16, Sinan Kaya wrote:
On 4/15/2018 11:17 PM, Bjorn Helgaas wrote:
It doesn't seem right to me that we handle both ERR_NONFATAL and
ERR_FATAL events differently if we happen to have DPC support in a
switch.
Maybe we should consider triggering DPC only on ERR_FATAL? That would
k
On 2018-04-16 18:57, Bjorn Helgaas wrote:
On Mon, Apr 16, 2018 at 11:33:13AM +0530, p...@codeaurora.org wrote:
On 2018-04-16 09:23, Sinan Kaya wrote:
> On 4/15/2018 11:16 PM, Bjorn Helgaas wrote:
> > On Mon, Apr 09, 2018 at 10:41:48AM -0400, Oza Pawandeep wrote:
> > > This patch set brings in er
On 2018-04-16 09:23, Sinan Kaya wrote:
On 4/15/2018 11:16 PM, Bjorn Helgaas wrote:
On Mon, Apr 09, 2018 at 10:41:48AM -0400, Oza Pawandeep wrote:
This patch set brings in error handling support for DPC
The current implementation of AER and error message broadcasting to
the
EP driver is tight
On 2018-04-16 11:03, p...@codeaurora.org wrote:
On 2018-04-16 08:47, Bjorn Helgaas wrote:
On Sat, Apr 14, 2018 at 11:53:17AM -0400, Sinan Kaya wrote:
You indicated that you want to unify the AER and DPC behavior. Let's
settle on what we want to do one more time. We have been going forth
and ba
On 2018-04-16 08:47, Bjorn Helgaas wrote:
On Sat, Apr 14, 2018 at 11:53:17AM -0400, Sinan Kaya wrote:
You indicated that you want to unify the AER and DPC behavior. Let's
settle on what we want to do one more time. We have been going forth
and back on the direction.
My thinking is that as muc
On 2018-04-10 04:55, Keith Busch wrote:
On Mon, Apr 09, 2018 at 10:41:53AM -0400, Oza Pawandeep wrote:
+/**
+ * pcie_wait_for_link - Wait for link till it's active/inactive
+ * @pdev: Bridge device
+ * @active: waiting for active or inactive ?
+ *
+ * Use this to wait till link becomes active or
On 2018-03-15 02:26, Keith Busch wrote:
On Wed, Mar 14, 2018 at 02:52:30PM -0600, Keith Busch wrote:
Reviewed-by: Keith Busch
Whoops, I accidentally truncated my message. My correct tag:
Reviewed-by: Keith Busch
Hi Bjorn,
Can this be merged ?
Regards,
Oza.
On 2018-03-15 02:22, Keith Busch wrote:
On Wed, Mar 14, 2018 at 09:20:48PM +0530, Oza Pawandeep wrote:
Current DPC driver acknowledges the interrupt in deferred work, which
works
since MSI are edge triggered.
But when MSI is disabled (e.g. pci=nomsi boot option) port service
driver falls back
On 2018-03-12 20:28, Keith Busch wrote:
On Mon, Mar 12, 2018 at 08:16:38PM +0530, p...@codeaurora.org wrote:
On 2018-03-12 19:55, Keith Busch wrote:
> On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote:
> > On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:
> > > On Wed, Feb 28, 2018 at 10:34:11
On 2018-03-12 19:55, Keith Busch wrote:
On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote:
On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:
> On Wed, Feb 28, 2018 at 10:34:11PM +0530, Oza Pawandeep wrote:
> That difference has been there since the beginning of DPC, so it has
> nothing to do
On 2018-03-12 03:33, Bjorn Helgaas wrote:
On Wed, Feb 28, 2018 at 10:34:11PM +0530, Oza Pawandeep wrote:
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 driv
On 2018-03-01 21:08, Bjorn Helgaas wrote:
Hi Oza,
On Wed, Jan 31, 2018 at 09:48:55PM +0530, Oza Pawandeep wrote:
Current dpc driver acknowledge the interrupt in deferred work, which
works
okay since LPI are edge triggered.
But when RP does not have MSI support, port service driver falls back
On 2018-03-06 19:32, Sinan Kaya wrote:
On 2/28/2018 12:04 PM, Oza Pawandeep wrote:
+struct pcie_port_service_driver *pcie_port_find_service(struct
pci_dev *dev,
+ u32 service)
+{
+ struct pcie_port_service_driver *drv = NULL;
Remove
On 2018-03-01 21:08, Bjorn Helgaas wrote:
Hi Oza,
On Wed, Jan 31, 2018 at 09:48:55PM +0530, Oza Pawandeep wrote:
Current dpc driver acknowledge the interrupt in deferred work, which
works
okay since LPI are edge triggered.
But when RP does not have MSI support, port service driver falls back
On 2018-02-24 21:11, Bjorn Helgaas wrote:
In subject:
s/pci/PCI/
sure.
On Fri, Feb 23, 2018 at 01:54:03PM +0530, Oza Pawandeep wrote:
Clients such as pciehp, dpc are using pcie_wait_link_active, which
waits
till the link becomes active or inactive.
Use "()" after function names so we have
On 2018-02-24 21:06, Bjorn Helgaas wrote:
On Fri, Feb 23, 2018 at 01:54:02PM +0530, Oza Pawandeep wrote:
This patch moves AER error defines to drivers/pci/pci.h.
So that it unifies the error repoting codes at single place along with
dpc
s/repoting/reporting/
s/dpc/DPC/ (in English text)
Sig
On 2018-02-24 05:37, Bjorn Helgaas wrote:
On Fri, Feb 23, 2018 at 01:54:01PM +0530, Oza Pawandeep wrote:
Current 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 pcie_do_recovery.
s/pcie_
On 2018-02-24 05:15, Bjorn Helgaas wrote:
On Fri, Feb 23, 2018 at 01:54:00PM +0530, Oza Pawandeep wrote:
This patch protects pci_do_recovery with mutex.
pcie_do_recovery()
Please explain why the mutex is necessary. What bad things happen
without the mutex?
You named (some) of the other thin
On 2018-02-26 11:02, p...@codeaurora.org wrote:
On 2018-02-24 05:12, Bjorn Helgaas wrote:
On Fri, Feb 23, 2018 at 01:53:59PM +0530, Oza Pawandeep wrote:
This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
Add blank line between paragraphs.
DPC shou
On 2018-02-24 05:12, Bjorn Helgaas wrote:
On Fri, Feb 23, 2018 at 01:53:59PM +0530, Oza Pawandeep wrote:
This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
Add blank line between paragraphs.
DPC should be able to register callbacks and attmept rec
On 2018-02-23 00:13, Christoph Hellwig wrote:
+/**
+ * pci__wait_for_link - Wait for link till its active/inactive
typo - just wants a single underscore.
+ pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
+ ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);
no need for t
On 2018-02-23 00:53, Randy Dunlap wrote:
On 02/21/2018 11:46 PM, Oza Pawandeep wrote:
Hi,
Just minor stuff:
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
new file mode 100644
index 000..a532fe0
--- /dev/null
+++ b/drivers/pci/pcie/pcie-err.c
@@ -0,0 +1,334 @@
+// S
On 2018-02-23 00:53, Randy Dunlap wrote:
On 02/21/2018 11:46 PM, Oza Pawandeep wrote:
Hi,
Just minor stuff:
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
new file mode 100644
index 000..a532fe0
--- /dev/null
+++ b/drivers/pci/pcie/pcie-err.c
@@ -0,0 +1,334 @@
+// S
On 2018-02-23 00:09, Christoph Hellwig wrote:
On Thu, Feb 22, 2018 at 09:32:09PM +0530, Oza Pawandeep wrote:
Current 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.
Signe
On 2018-02-23 00:06, Christoph Hellwig wrote:
On Thu, Feb 22, 2018 at 09:32:08PM +0530, Oza Pawandeep wrote:
This patch protects pci_do_recovery with mutex.
Do we really want a global mutex for this and not one per root complex
at very least?
This protects pcie_do_recovery, which is called b
On 2018-02-23 00:04, Christoph Hellwig wrote:
On Thu, Feb 22, 2018 at 09:32:06PM +0530, Oza Pawandeep wrote:
This patch renames error recovery to generic name with pci prefix
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
in
On 2018-02-23 00:53, Randy Dunlap wrote:
On 02/21/2018 11:46 PM, Oza Pawandeep wrote:
Implement error_resume callback in DPC so, after DPC trigger event
enumerates the devices beneath.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index fc
On 2018-02-23 00:53, Randy Dunlap wrote:
On 02/21/2018 11:46 PM, Oza Pawandeep wrote:
Current 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.
Hi,
What does DPC mean?
On 2018-02-22 21:32, Oza Pawandeep wrote:
This patch moves AER error defines to drivers/pci/pci.h.
So that it unifies the error repoting codes at single place along with
dpc
Signed-off-by: Oza Pawandeep
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..7ae9bb3 1
On 2018-01-20 12:05, Oza Pawandeep wrote:
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 hand
On 2018-01-19 19:47, Sinan Kaya wrote:
On 1/19/2018 6:10 AM, Oza Pawandeep wrote:
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -150,37 +150,9 @@ static void dpc_wait_link_inactive(struct dpc_dev
*dpc)
struct pci_dev *pdev = dpc->dev->port;
struct device *dev = &dpc->dev->device;
On 2018-01-19 19:49, Stefan Roese wrote:
On 19.01.2018 12:10, Oza Pawandeep wrote:
Clients such as pciehp, dpc are using pcie_wait_link_active, which
waits
till the link becomes active or inactive.
Made generic function and moved it to drivers/pci/pci.c
Signed-off-by: Oza Pawandeep
diff --g
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 di
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
On 2018-01-19 07:13, Keith Busch wrote:
On Thu, Jan 18, 2018 at 11:35:59AM -0500, Sinan Kaya wrote:
On 1/18/2018 12:32 AM, p...@codeaurora.org wrote:
> On 2018-01-18 08:26, Keith Busch wrote:
>> On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote:
>>> On 1/17/2018 5:37 AM, Oza Pawandeep w
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
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
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 /
On 2018-01-18 08:26, Keith Busch wrote:
On Wed, Jan 17, 2018 at 08:27:39AM -0800, Sinan Kaya wrote:
On 1/17/2018 5:37 AM, Oza Pawandeep wrote:
> +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
On 2018-01-17 21:57, Sinan Kaya wrote:
On 1/17/2018 5:37 AM, Oza Pawandeep wrote:
+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 p
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
1 - 100 of 108 matches
Mail list logo
