[PATCH net-next 0/4] can: don't discard the platform_get_irq() error in probe

[PATCH net-next 0/4] can: don't discard the platform_get_irq() error in probe

[Chaosheng Qu]

Four CAN platform drivers collapse every failure of platform_get_irq()
into a fixed error code:

    sun4i_can    -ENODEV
    at91_can     -ENODEV  (also tests irq <= 0, which cannot happen)
    janz-ican3   -ENODEV
    ifi_canfd    -EINVAL

sun4i_can, at91_can and ifi_canfd match through an of_match_table, so
of_irq_get() returns -EPROBE_DEFER while the interrupt controller has not
been probed. The probes overwrite it and the driver core stops retrying,
leaving the device unbound even though the interrupt controller appears
later.

janz-ican3 is different. The device is an MFD child of janz-cmodio, which
takes the interrupt from the carrier board's PCI device, and the driver
has neither an of_match_table nor an ACPI match, so it cannot see
-EPROBE_DEFER. Its commit message says so: that one is about the probe
not inventing an error code for a lookup that failed for another reason.

The patches return the lookup error unchanged, which is what the
neighbouring CAN platform drivers do, e.g. commit 057bd6168d98 ("can:
cc770: don't discard the IRQ lookup error in probe") and, from 2023,
commit 53b8d2be4d71 ("can: flexcan: fix the return value handle for
platform_get_irq()"). The 2023 sweep covered flexcan and c_can and missed
these four.

at91_can additionally has to split its combined lookup, because the
memory resource and the interrupt are currently checked in one condition
that returns -ENODEV for both. The memory resource keeps -ENODEV.

The only visible change is the error code for a device tree without an
interrupt: -ENXIO instead of -ENODEV or -EINVAL. The driver core treats
both as a failed probe.

All four apply with git am to mkl/linux-can-next testing and build
without new warnings on x86_64 with CAN_SUN4I, CAN_AT91, CAN_JANZ_ICAN3
and CAN_IFI_CANFD enabled; checkpatch.pl --strict is clean. None of the
four controllers is available here, so this is build tested only.

Assisted-by: LLM

Chaosheng Qu (4):
  can: sun4i_can: don't discard the IRQ lookup error in probe
  can: at91_can: don't discard the IRQ lookup error in probe
  can: janz-ican3: don't discard the IRQ lookup error in probe
  can: ifi_canfd: don't discard the IRQ lookup error in probe

 drivers/net/can/at91_can.c            | 9 +++++++--
 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 drivers/net/can/janz-ican3.c          | 2 +-
 drivers/net/can/sun4i_can.c           | 2 +-
 4 files changed, 10 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH net-next 1/4] can: sun4i_can: don't discard the IRQ lookup error in probe

[Chaosheng Qu]

sun4ican_probe() collapses every failure of platform_get_irq() into
-ENODEV:

	irq = platform_get_irq(pdev, 0);
	if (irq < 0) {
		err = -ENODEV;
		goto exit_put_clk;
	}

The driver matches through an of_match_table, so of_irq_get() returns
-EPROBE_DEFER while the interrupt controller has not been probed. The
probe overwrites it and the driver core stops retrying, leaving the
device unbound even though the interrupt controller appears later.

Return the lookup error unchanged, which is what the neighbouring CAN
platform drivers do, e.g. commit 057bd6168d98 ("can: cc770: don't
discard the IRQ lookup error in probe").

A device tree without an interrupt now reports -ENXIO rather than
-ENODEV; the driver core treats both as a failed probe.

Build tested on x86_64.

Assisted-by: LLM
Signed-off-by: Chaosheng Qu <chaosheng.qu.linux@gmail.com>
---
 drivers/net/can/sun4i_can.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c
index 76db6d09d1e6..a6c761506244 100644
--- a/drivers/net/can/sun4i_can.c
+++ b/drivers/net/can/sun4i_can.c
@@ -856,7 +856,7 @@ static int sun4ican_probe(struct platform_device *pdev)
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0) {
-		err = -ENODEV;
+		err = irq;
 		goto exit_put_clk;
 	}
 
-- 
2.43.0

[PATCH net-next 2/4] can: at91_can: don't discard the IRQ lookup error in probe

[Chaosheng Qu]

at91_can_probe() looks up the memory resource and the interrupt together
and collapses both failures into -ENODEV:

	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	irq = platform_get_irq(pdev, 0);
	if (!res || irq <= 0) {
		err = -ENODEV;
		goto exit_put;
	}

The driver matches through an of_match_table, so of_irq_get() returns
-EPROBE_DEFER while the interrupt controller has not been probed. The
probe overwrites it and the driver core stops retrying, leaving the
device unbound even though the interrupt controller appears later.

The irq <= 0 test also covers a 0 return, which platform_get_irq() never
produces; it warns and returns -EINVAL instead.

Split the two lookups: the memory resource keeps -ENODEV, the interrupt
returns the lookup error unchanged, as the neighbouring CAN platform
drivers do, e.g. commit 057bd6168d98 ("can: cc770: don't discard the IRQ
lookup error in probe"). This also drops an IRQ lookup that cannot
succeed when the memory resource is missing.

A device tree without an interrupt now reports -ENXIO rather than
-ENODEV; the driver core treats both as a failed probe.

Build tested on x86_64.

Assisted-by: LLM
Signed-off-by: Chaosheng Qu <chaosheng.qu.linux@gmail.com>
---
 drivers/net/can/at91_can.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 58da323f14d7..3977de761636 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -1069,12 +1069,17 @@ static int at91_can_probe(struct platform_device *pdev)
 	}
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	irq = platform_get_irq(pdev, 0);
-	if (!res || irq <= 0) {
+	if (!res) {
 		err = -ENODEV;
 		goto exit_put;
 	}
 
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		err = irq;
+		goto exit_put;
+	}
+
 	if (!request_mem_region(res->start,
 				resource_size(res),
 				pdev->name)) {
-- 
2.43.0

[PATCH net-next 3/4] can: janz-ican3: don't discard the IRQ lookup error in probe

[Chaosheng Qu]

ican3_probe() collapses every failure of platform_get_irq() into
-ENODEV:

	mod->irq = platform_get_irq(pdev, 0);
	if (mod->irq < 0) {
		ret = -ENODEV;
		goto out_free_ndev;
	}

Return the lookup error unchanged, as the neighbouring CAN platform
drivers do, e.g. commit 057bd6168d98 ("can: cc770: don't discard the IRQ
lookup error in probe").

This driver cannot see -EPROBE_DEFER and the change does not fix a
deferred probe. The device is an MFD child of janz-cmodio, which takes
the interrupt from the carrier board's PCI device, and the driver has
neither an of_match_table nor an ACPI match. The probe should not invent
an error code for a lookup that failed for another reason.

Build tested on x86_64.

Assisted-by: LLM
Signed-off-by: Chaosheng Qu <chaosheng.qu.linux@gmail.com>
---
 drivers/net/can/janz-ican3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index 1efdd1fd8caa..a65326b0f11e 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -1944,7 +1944,7 @@ static int ican3_probe(struct platform_device *pdev)
 	/* find our IRQ number */
 	mod->irq = platform_get_irq(pdev, 0);
 	if (mod->irq < 0) {
-		ret = -ENODEV;
+		ret = mod->irq;
 		goto out_free_ndev;
 	}
 
-- 
2.43.0

[PATCH net-next 4/4] can: ifi_canfd: don't discard the IRQ lookup error in probe

[Chaosheng Qu]

ifi_canfd_plat_probe() maps every failure of platform_get_irq() to
-EINVAL:

	irq = platform_get_irq(pdev, 0);
	if (irq < 0)
		return -EINVAL;

The driver matches through an of_match_table ("ifi,canfd-1.0"), so
of_irq_get() returns -EPROBE_DEFER while the interrupt controller has not
been probed. The probe overwrites it and the driver core stops retrying,
leaving the device unbound even though the interrupt controller appears
later.

Return the lookup error unchanged, as the neighbouring CAN platform
drivers do, e.g. commit 057bd6168d98 ("can: cc770: don't discard the IRQ
lookup error in probe").

A device tree without an interrupt now reports -ENXIO rather than
-EINVAL; the driver core treats both as a failed probe.

Build tested on x86_64.

Assisted-by: LLM
Signed-off-by: Chaosheng Qu <chaosheng.qu.linux@gmail.com>
---
 drivers/net/can/ifi_canfd/ifi_canfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c b/drivers/net/can/ifi_canfd/ifi_canfd.c
index 9eecfe5a87bd..e0f5abd934fa 100644
--- a/drivers/net/can/ifi_canfd/ifi_canfd.c
+++ b/drivers/net/can/ifi_canfd/ifi_canfd.c
@@ -965,7 +965,7 @@ static int ifi_canfd_plat_probe(struct platform_device *pdev)
 
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0)
-		return -EINVAL;
+		return irq;
 
 	id = readl(addr + IFI_CANFD_IP_ID);
 	if (id != IFI_CANFD_IP_ID_VALUE) {
-- 
2.43.0

Re: [PATCH net-next 0/4] can: don't discard the platform_get_irq() error in probe

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net-next 0/4] can: don't discard the platform_get_irq() error in probe

[chaosheng.qu.linux]

Hi,

The issue was identified during development while reviewing the probe error handling in these CAN platform drivers. Manual inspection showed that negative results from platform_get_irq() were being replaced with fixed error codes. For drivers matched via OF, this can discard -EPROBE_DEFER and prevent the driver core from retrying once the interrupt controller becomes available. I compared these paths with platform_get_irq() semantics and neighboring drivers.

This was not a production hit or a syzbot report, and it was not found by a static-analysis scan. LLM assistance was used in preparing the patches, as disclosed by the Assisted-by tag. The controllers were unavailable for runtime testing, so the series was build-tested only.

Thanks,
Chaosheng