[PATCH v4 4/4] PCI: cadence: Check link is up before sending IRQ from EP

If EP attempts to send an IRQ (legacy, MSI or MSI-X) while the
link is not up, return -EINVAL

Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller")
Signed-off-by: Alan Douglas <redacted>
---
 drivers/pci/controller/pcie-cadence-ep.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c
index b762214..3667d70 100644
--- a/drivers/pci/controller/pcie-cadence-ep.c
+++ b/drivers/pci/controller/pcie-cadence-ep.c

@@ -370,6 +370,12 @@ static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
 				  u16 interrupt_num)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 link_status;
+
+	/* Can't send an IRQ if the link is down. */
+	link_status = cdns_pcie_readl(&ep->pcie, CDNS_PCIE_LM_BASE);
+	if (!(link_status & 0x1))
+		return -EINVAL;
 
 	switch (type) {
 	case PCI_EPC_IRQ_LEGACY:

-- 
1.9.0

On Thu, Oct 11, 2018 at 05:16:57PM +0100, Alan Douglas wrote:

This looks racy.  What happens if the link goes down right after the
CDNS_PCIE_LM_BASE read, but before we get here?

 	switch (type) {
 	case PCI_EPC_IRQ_LEGACY:
-- 
1.9.0

On Mon, Oct 15, 2018 at 04:30:35PM -0500, Bjorn Helgaas wrote:

On Thu, Oct 11, 2018 at 05:16:57PM +0100, Alan Douglas wrote:

quoted

If EP attempts to send an IRQ (legacy, MSI or MSI-X) while the
link is not up, return -EINVAL

Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller")
Signed-off-by: Alan Douglas <redacted>
---
 drivers/pci/controller/pcie-cadence-ep.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c
index b762214..3667d70 100644
--- a/drivers/pci/controller/pcie-cadence-ep.c
+++ b/drivers/pci/controller/pcie-cadence-ep.c

@@ -370,6 +370,12 @@ static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
 				  u16 interrupt_num)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 link_status;
+
+	/* Can't send an IRQ if the link is down. */
+	link_status = cdns_pcie_readl(&ep->pcie, CDNS_PCIE_LM_BASE);
+	if (!(link_status & 0x1))
+		return -EINVAL;

This looks racy.  What happens if the link goes down right after the
CDNS_PCIE_LM_BASE read, but before we get here?

I agree with Bjorn, this check does not seem very useful and honestly
I think this patch should be dropped, I should not have queued it in
the first place.

I wonder whether something can actually be done in the EP subsystem
to handle this in a cleaner way.

Unless I hear a compelling reason to keep it in the patch queue I
would drop this patch.

Lorenzo

Hi,

On 16 October 2018 14:53, Lorenzo Pieralisi [off-list ref] wrote:

On Mon, Oct 15, 2018 at 04:30:35PM -0500, Bjorn Helgaas wrote:

quoted

On Thu, Oct 11, 2018 at 05:16:57PM +0100, Alan Douglas wrote:

quoted

If EP attempts to send an IRQ (legacy, MSI or MSI-X) while the
link is not up, return -EINVAL

Fixes: 37dddf14f1ae ("PCI: cadence: Add EndPoint Controller driver for Cadence PCIe controller")
Signed-off-by: Alan Douglas <redacted>
---
 drivers/pci/controller/pcie-cadence-ep.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c
index b762214..3667d70 100644
--- a/drivers/pci/controller/pcie-cadence-ep.c
+++ b/drivers/pci/controller/pcie-cadence-ep.c

@@ -370,6 +370,12 @@ static int cdns_pcie_ep_raise_irq(struct pci_epc *epc, u8 fn,
 				  u16 interrupt_num)
 {
 	struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+	u32 link_status;
+
+	/* Can't send an IRQ if the link is down. */
+	link_status = cdns_pcie_readl(&ep->pcie, CDNS_PCIE_LM_BASE);
+	if (!(link_status & 0x1))
+		return -EINVAL;

This looks racy.  What happens if the link goes down right after the
CDNS_PCIE_LM_BASE read, but before we get here?

I agree with Bjorn, this check does not seem very useful and honestly
I think this patch should be dropped, I should not have queued it in
the first place.

I wonder whether something can actually be done in the EP subsystem
to handle this in a cleaner way.

Unless I hear a compelling reason to keep it in the patch queue I
would drop this patch.

Lorenzo

Makes sense to me, I was just preparing a reply.  I need to find
a fix that will work for all cases, possibly using the handshake
for the D0->D3 Config write which should precede the link down. At
the moment I think we need to insist that the link is always up while
the EP driver is loaded.

Alan