Messages in this thread Patch in this message | ![/](/images/icornerl.gif) | | From | Uwe Kleine-König <> | Subject | [PATCH v2] driver core: Better advertise dev_err_probe() | Date | Fri, 15 Dec 2023 18:45:41 +0100 |
| |
Describing the usage of dev_err_probe() as being (only?) "deemed acceptable" has a bad connotation. In fact dev_err_probe() fulfills three tasks:
- handling of EPROBE_DEFER (even more than degrading to dev_dbg()) - symbolic output of the error code - return err for compact error code paths
Advertise these better and claim the usage to be "fine" to get rid of the bad connotation.
Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- Changes since (implicit) v1:
- Send it to a public mailing list (how embarrassing I failed to do that for v1 already) - Fix a wrong word in the commit log - Add Rafael's Ack.
drivers/base/core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c index 6736c1de3ba4..14d46af40f9a 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -4944,13 +4944,14 @@ define_dev_printk_level(_dev_info, KERN_INFO); * * return dev_err_probe(dev, err, ...); * - * Note that it is deemed acceptable to use this function for error - * prints during probe even if the @err is known to never be -EPROBE_DEFER. + * Using this helper in your probe function is totally fine even if @err is + * known to never be -EPROBE_DEFER. * The benefit compared to a normal dev_err() is the standardized format - * of the error code and the fact that the error code is returned. + * of the error code, it being emitted symbolically (i.e. you get "EAGAIN" + * instead of "-35") and the fact that the error code is returned which allows + * more compact error paths. * * Returns @err. - * */ int dev_err_probe(const struct device *dev, int err, const char *fmt, ...) { -- 2.42.0
| ![\](/images/icornerr.gif) |