Hello, On Sun, Mar 05, 2023 at 06:31:08AM -0800, Guenter Roeck wrote: > On Sun, Mar 05, 2023 at 12:15:00PM +0100, Uwe Kleine-König wrote: > > On Sat, Mar 04, 2023 at 02:10:47PM -0800, Guenter Roeck wrote: > > > The primary reason to call dev_err_probe() is that the error may be > > > -EPROBE_DEFER, in which case the error message is suppressed. > > > That is not the case for those two functions; they never return > > > -EPROBE_DEFER. Calling dev_err_probe() would give the false impression > > > that the functions _might_ return -EPROBE_DEFER. > > > > That is subjective. In my book dev_err_probe() handling -EPROBE_DEFER is > > only one aspect. Another is that using it allows to have return and error > > message in a single line and also that if already other exit paths use > > it to get a consistent style for the emitted messages. Having said that > > *I* wouldn't assume that the previous call might return -EPROBE_DEFER > > just because dev_err_probe() is used. > > > > Having said that, I also don't think there is much harm if someone > > thinks that a given function (here devm_request_irq()) might return > > -EPROBE_DEFER. > > > > I guess we'll have to agree to disagree. I don't agree to disagree. In my eyes you weight the corresponding facts in an irrational way. To have some code changes to talk about, I created this series (on top of Guenter's patches to this driver from Saturday [1]). Patch 1 is necessary to effectively make use of dev_err_probe(). I admit this annoys me a bit as it shows that dev_err_probe() isn't a plug-in replacement, but given that it reduces the binary size a bit, it has at least positive usefulness. (But maybe this is subjective? *shrug*) Patch 2 unifies the format of the error messages between the error paths that make use of dev_err_probe() and those that (only) use dev_err(). IMHO this has mixed value, but still positive in sum. While having a consistent error log style is nice, having to manually use dev_err_probe()'s style is a bit ugly. Together with a) the messages get more useful mentioning the error code and b) the downside is removed by patch 3, I still like it. (And if you don't because of b), please consider squashing patches 2 and 3 together. In fact I only created patch 2 to make the upsides for patch 3 more obvious and I don't mind a squash.) Patch 3 does the actual conversion to dev_err_probe() for all error paths in .probe(). The (unarguable?) upsides are: - Reduced line count - Reduced binary size (and the reduction mentioned in the commit log doesn't even account for the shorter format strings!) The fact where Guenter doesn't agree to me (and Krzysztof) is: - You cannot any more defer from the usage of dev_err_probe() vs. dev_err() if the function that failed before might return -EPROBE_DEFER. In my eyes this is irrelevant because there is no objective reason to have to know that. If the function might return -EPROBE_DEFER or not shouldn't (and doesn't!) have an influence on how the driver should behave in the error case. Also the ability to defer that property is very unreliable. It's not even reliable in drivers/watchdog, look at how imx2_wdt handles devm_clk_get() or keembay_wdt handles clk_get_rate() returning zero. So using dev_err_probe() has two big benefits in contrast to a dubious and unreliable connection between -EPROBE_DEFER and dev_err_probe(). Best regards Uwe [1] https://lore.kernel.org/linux-watchdog/20230304165653.2179835-1-linux@xxxxxxxxxxxx Uwe Kleine-König (3): watchdog: s3c2410_wdt: Fold s3c2410_get_wdt_drv_data() into only caller watchdog: s3c2410_wdt: Unify error logging format in probe function watchdog: s3c2410_wdt: Simplify using dev_err_probe() drivers/watchdog/s3c2410_wdt.c | 93 ++++++++++++++-------------------- 1 file changed, 37 insertions(+), 56 deletions(-) base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6 prerequisite-patch-id: 775bdd863307268e1ef16250bf2f40862637b453 prerequisite-patch-id: 924ddfbe583e97e7c9a46c2460ecbc88c29ee319 -- 2.39.1
