From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 1/2] of: platform: return -EPROBE_DEFER when ensuring probe with driver missing
Date: Fri, 16 Feb 2024 23:06:48 +0100 [thread overview]
Message-ID: <20240216220649.2328345-1-a.fatoum@pengutronix.de> (raw)
-ENODEV is a bad choice for an error code for of_device_ensure_probed.
The function is either called from board code or from driver frameworks,
which usually just propagate the error code with unintended
consequences:
- A board driver probe function returning -ENODEV is silently skipped
- A driver framework function returning -ENODEV is often interpreted
to mean that an optional resource is not specified (e.g. in DT).
In both cases, the user isn't provided an error message and wrong
behavior can crop up later. In my case, the XHCI driver would time out,
because phy_get propagated of_device_ensure_probed's -ENODEV, which was
understood to mean that no PHY is needed and not that the PHY is
specified in the DT, but no driver was bound to it.
Instead of -ENODEV, let's thus return -EPROBE_DEFER. This can be
propagated up to the driver core, which on a deep probe system (the only
ones where of_device_ensure_probed is not a no-op) will print a fat red
error message. We could achieve the same with some other error code, but
-EPROBE_DEFER is what a non-deep-probe system would return when probes
are deferred indefinitely, so symmetry in the deep probe case fits well.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/of/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 060fa3458bd2..664af49d268f 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -504,7 +504,7 @@ int of_device_ensure_probed(struct device_node *np)
* requirements are fulfilled if 'dev->driver' is not NULL.
*/
if (!dev->driver)
- return -ENODEV;
+ return -EPROBE_DEFER;
return 0;
}
--
2.39.2
next reply other threads:[~2024-02-16 22:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-16 22:06 Ahmad Fatoum [this message]
2024-02-16 22:06 ` [PATCH 2/2] phy: freescale: imx8mq-usb: make i.MX8MP support more explicit Ahmad Fatoum
2024-02-16 23:02 ` [PATCH 1/2] of: platform: return -EPROBE_DEFER when ensuring probe with driver missing Marco Felsch
2024-02-17 9:16 ` Ahmad Fatoum
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=20240216220649.2328345-1-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.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