On Wed, 26 Feb 2020, Greg Ungerer wrote:
On 26/2/20 4:39 pm, Finn Thain wrote:
If -EBUSY means the end user has misconfigured something, printing
"request_irq failed" would be helpful. But does that still happen?
I have seen it many times. Its not at all difficult to get interrupt
assignments wrong, duplicated, or otherwise mistaken when creating
device trees. Not so much m68k/coldfire platforms where they are most
commonly hard coded.
I was thinking of end users and production builds. You seem to be
concerned about developers. Catering to developers argues for pr_debug()
here, if anything.
You say you've seen -16 errors "many times". Have you also seen -22? Did
the ability to distinguish these values help you to fix your device tree?
...
BTW, one of the benefits of "%s: request_irq failed" is that a
compilation unit with multiple request_irq calls permits the compiler
to coalesce all duplicated format strings. Whereas, that's not
possible with "foo: request_irq failed" and "bar: request_irq failed".
Given the wide variety of message text used with failed request_irq()
calls it would be shear luck that this matched anything else. A quick
grep shows that "%s: request_irq() failed\n" has no other exact matches
in the current kernel source.
You are overlooking the patches in this series that produce multiple
identical format strings.
And the present lack of consistency isn't a great argument for more
inconsistency IMO.
