All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@linux-m68k.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: afzal mohammed <afzal.mohd.ma@gmail.com>,
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v2 06/18] m68k: Replace setup_irq() by request_irq()
Date: Thu, 27 Feb 2020 16:37:04 +1000	[thread overview]
Message-ID: <1a16c680-2bbe-eb24-6ea3-4b50d0c3e377@linux-m68k.org> (raw)
In-Reply-To: <alpine.LNX.2.22.394.2002270908380.8@nippy.intranet>


On 27/2/20 8:31 am, Finn Thain wrote:
> 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.

Perhaps. But most of the kernel boot output as it stands today
is more debug (or maybe notice) than useful.


> 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?

Probably not. But the real difficulty is trying to diagnose other
peoples problems with just console trace output. The more information
there the better.


>>> ...
>>>
>>> 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.

No I didn't :-)  None of these will end up compiled in at the same time.
The various ColdFire SoC parts have a single timer hardware module -
and only the required one will be compiled in, not all of them.

Regards
Greg

  reply	other threads:[~2020-02-27  6:37 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24  0:47 [PATCH v2 00/18] genirq: Remove setup_irq() afzal mohammed
2020-02-24  0:59 ` afzal mohammed
2020-02-24  0:47 ` afzal mohammed
2020-02-24  0:48 ` [PATCH v2 01/18] alpha: replace setup_irq() by request_irq() afzal mohammed
2020-02-24  0:49 ` [PATCH v2 02/18] ARM: " afzal mohammed
2020-02-24  0:49   ` afzal mohammed
2020-02-24 10:13   ` Lubomir Rintel
2020-02-24 10:13     ` Lubomir Rintel
2020-02-26 16:31   ` Tony Lindgren
2020-02-26 16:31     ` Tony Lindgren
2020-02-24  0:49 ` [PATCH v2 03/18] c6x: " afzal mohammed
2020-02-24  0:49 ` [PATCH v2 04/18] hexagon: " afzal mohammed
2020-02-24  0:49 ` [PATCH v2 05/18] ia64: " afzal mohammed
2020-02-24  0:49   ` afzal mohammed
2020-02-24  0:50 ` [PATCH v2 06/18] m68k: Replace " afzal mohammed
2020-02-26  0:42   ` Greg Ungerer
2020-02-26  1:11     ` Finn Thain
2020-02-26  2:11       ` Greg Ungerer
2020-02-26  6:39         ` Finn Thain
2020-02-26 12:26           ` Greg Ungerer
2020-02-26 22:31             ` Finn Thain
2020-02-27  6:37               ` Greg Ungerer [this message]
2020-02-27 22:19                 ` Finn Thain
2020-02-27  8:18     ` afzal mohammed
2020-02-27  8:32       ` Geert Uytterhoeven
2020-02-27 12:06         ` afzal mohammed
2020-02-27 22:38           ` Finn Thain
2020-02-29 12:41             ` afzal mohammed
2020-02-28  7:05       ` Greg Ungerer
2020-02-29 12:47         ` afzal mohammed
2020-02-29 13:15   ` afzal mohammed
2020-02-29 23:11     ` Finn Thain
2020-03-01  1:05       ` afzal mohammed
2020-03-01  3:26         ` Finn Thain
2020-03-01  6:13           ` afzal mohammed
2020-03-02  6:26             ` Finn Thain
2020-03-04  1:24               ` afzal mohammed
2020-02-24  0:50 ` [PATCH v2 07/18] microblaze: " afzal mohammed
2020-02-24  0:50 ` [PATCH v2 08/18] MIPS: " afzal mohammed
2020-02-24  0:50   ` afzal mohammed
2020-02-24  0:51 ` [PATCH v2 09/18] parisc: " afzal mohammed
2020-02-24  0:51 ` [PATCH v2 10/18] powerpc: " afzal mohammed
2020-02-24  0:51   ` afzal mohammed
2020-02-24  0:51 ` [PATCH v2 11/18] s390: replace " afzal mohammed
2020-02-24  0:51 ` [PATCH v2 12/18] sh: " afzal mohammed
2020-02-24  0:51   ` afzal mohammed
2020-02-24  0:52 ` [PATCH v2 13/18] unicore32: " afzal mohammed
2020-02-24  0:52 ` [PATCH v2 14/18] x86: Replace " afzal mohammed
2020-02-24  0:52 ` [PATCH v2 15/18] xtensa: replace " afzal mohammed
2020-02-24  0:52 ` [PATCH v2 16/18] clocksource: Replace " afzal mohammed
2020-02-24  0:52   ` afzal mohammed
2020-02-24  0:52   ` afzal mohammed
2020-02-25  2:52   ` kbuild test robot
2020-02-25  2:52     ` kbuild test robot
2020-02-25  2:52     ` kbuild test robot
2020-02-25  2:52     ` kbuild test robot
2020-02-25  7:51     ` afzal mohammed
2020-02-25  7:51       ` afzal mohammed
2020-02-25  7:51       ` afzal mohammed
2020-02-27 10:59     ` [PATCH v3 " afzal mohammed
2020-02-27 10:59       ` afzal mohammed
2020-02-27 10:59       ` afzal mohammed
2020-02-27 11:18       ` Daniel Lezcano
2020-02-27 11:18         ` Daniel Lezcano
2020-02-27 11:18         ` Daniel Lezcano
2020-03-12  6:48         ` [PATCH v4] clocksource/drivers/timer-cs5535: request irq with non-NULL dev_id afzal mohammed
2020-03-12  6:48           ` afzal mohammed
2020-03-12  6:48           ` afzal mohammed
2020-03-12  7:10           ` afzal mohammed
2020-03-12  7:10             ` afzal mohammed
2020-03-12  7:10             ` afzal mohammed
2020-03-12 18:23           ` Daniel Lezcano
2020-03-12 18:23             ` Daniel Lezcano
2020-03-12 18:23             ` Daniel Lezcano
2020-03-19  8:47           ` [tip: timers/core] clocksource/drivers/timer-cs5535: Request " tip-bot2 for afzal mohammed
2020-04-16 16:08           ` [PATCH v4] clocksource/drivers/timer-cs5535: request " patchwork-bot+linux-amlogic
2020-02-24  0:53 ` [PATCH v2 17/18] irqchip: Replace setup_irq() by request_irq() afzal mohammed
2020-02-24  0:53 ` [PATCH v2 18/18] genirq: Remove setup_irq() and remove_irq() afzal mohammed

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=1a16c680-2bbe-eb24-6ea3-4b50d0c3e377@linux-m68k.org \
    --to=gerg@linux-m68k.org \
    --cc=afzal.mohd.ma@gmail.com \
    --cc=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.