From: Chaosheng Qu <chaosheng.qu.linux@gmail.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
Vincent Mailhol <mailhol@kernel.org>
Cc: Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
linux-can@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH net-next 0/4] can: don't discard the platform_get_irq() error in probe
Date: Fri, 16 Oct 2026 14:11:35 +0800 [thread overview]
Message-ID: <cover.1792118040.git.chaosheng.qu.linux@gmail.com> (raw)
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
next reply other threads:[~2026-10-16 6:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 6:11 Chaosheng Qu [this message]
2026-10-16 6:11 ` [PATCH net-next 1/4] can: sun4i_can: don't discard the IRQ lookup error in probe Chaosheng Qu
2026-10-16 6:11 ` [PATCH net-next 2/4] can: at91_can: " Chaosheng Qu
2026-10-16 6:11 ` [PATCH net-next 3/4] can: janz-ican3: " Chaosheng Qu
2026-10-16 6:11 ` [PATCH net-next 4/4] can: ifi_canfd: " Chaosheng Qu
2026-10-16 6:15 ` [PATCH net-next 0/4] can: don't discard the platform_get_irq() " netdev-bot+sinfo
2026-10-16 7:16 ` chaosheng.qu.linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1792118040.git.chaosheng.qu.linux@gmail.com \
--to=chaosheng.qu.linux@gmail.com \
--cc=alexandre.belloni@bootlin.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=jernej.skrabec@gmail.com \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mailhol@kernel.org \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=samuel@sholland.org \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).