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: Wed, 26 Feb 2020 12:11:38 +1000 [thread overview]
Message-ID: <caa5686a-5be3-5848-fdee-36f54237ccb6@linux-m68k.org> (raw)
In-Reply-To: <alpine.LNX.2.22.394.2002261151220.9@nippy.intranet>
On 26/2/20 11:11 am, Finn Thain wrote:
> On Wed, 26 Feb 2020, Greg Ungerer wrote:
>> On 24/2/20 10:50 am, afzal mohammed wrote:
>>> request_irq() is preferred over setup_irq(). The early boot setup_irq()
>>> invocations happen either via 'init_IRQ()' or 'time_init()', while
>>> memory allocators are ready by 'mm_init()'.
>>>
>>> Per tglx[1], setup_irq() existed in olden days when allocators were not
>>> ready by the time early interrupts were initialized.
>>>
>>> Hence replace setup_irq() by request_irq().
>>>
>>> Seldom remove_irq() usage has been observed coupled with setup_irq(),
>>> wherever that has been found, it too has been replaced by free_irq().
>>>
>>> [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos
>>>
>>> Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com>
>>> Tested-by: Greg Ungerer <gerg@linux-m68k.org> # ColdFire
>>> ---
>>>
>>> v2:
>>> * Replace pr_err("request_irq() on %s failed" by
>>> pr_err("%s: request_irq() failed"
>>> * Commit message massage
>>> * remove now irrelevant comment lines at 3 places
>>>
>>> arch/m68k/68000/timers.c | 11 ++---------
>>> arch/m68k/coldfire/pit.c | 11 ++---------
>>> arch/m68k/coldfire/sltimers.c | 19 +++++--------------
>>> arch/m68k/coldfire/timers.c | 21 +++++----------------
>>> 4 files changed, 14 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c
>>> index 71ddb4c98726..55a76a2d3d58 100644
>>> --- a/arch/m68k/68000/timers.c
>>> +++ b/arch/m68k/68000/timers.c
>>> @@ -68,14 +68,6 @@ static irqreturn_t hw_tick(int irq, void *dummy)
>>> /***************************************************************************/
>>> -static struct irqaction m68328_timer_irq = {
>>> - .name = "timer",
>>> - .flags = IRQF_TIMER,
>>> - .handler = hw_tick,
>>> -};
>>> -
>>>
>>> -/***************************************************************************/
>>> -
>>> static u64 m68328_read_clk(struct clocksource *cs)
>>> {
>>> unsigned long flags;
>>> @@ -106,7 +98,8 @@ void hw_timer_init(irq_handler_t handler)
>>> TCTL = 0;
>>> /* set ISR */
>>> - setup_irq(TMR_IRQ_NUM, &m68328_timer_irq);
>>> + if (request_irq(TMR_IRQ_NUM, hw_tick, IRQF_TIMER, "timer", NULL))
>>> + pr_err("%s: request_irq() failed\n", "timer");
>>
>> Why not just:
>>
>> pr_err("timer: request_irq() failed\n");
>>
>
> I believe that the compiler would coalesce the two "timer" string
> constants in the patch from Afzal (as per my suggestion).>
> I suspect that your version costs a few extra bytes everywhere it appears
> (but I didn't check).
Maybe. It costs some extra code for another argument push and a bunch
of cycles to process the %s at run time though (if triggered).
The profile timer setup is not commonly used, so in most typical
builds there is no scope for coalescing the same string. So in the end
most builds will be a few bytes larger with the separated strings.
But really that is not the point. It just seems simpler and clearer to
me to put the string in place - all in one.
>> And maybe would it be useful to print out the error return code from a
>> failed request_irq()? What about displaying the requested IRQ number as
>> well? Just a thought.
>>
>
> That error would almost always be -EBUSY, right?
I expect it will never fail this early in boot.
But how will you know if it really is EBUSY if you don't print it out?
> Moreover, compare this change,
>
> - setup_irq(TMR_IRQ_NUM, &m68328_timer_irq);
> + request_irq(TMR_IRQ_NUM, hw_tick, IRQF_TIMER, "timer", NULL);
>
> with this change,
>
> + int err;
>
> - setup_irq(TMR_IRQ_NUM, &m68328_timer_irq);
> + err = request_irq(TMR_IRQ_NUM, hw_tick, IRQF_TIMER, "timer", NULL);
> + if (err)
> + return err;
>
> Isn't the latter change the more common pattern? It prints nothing.
Hmm, in my experience the much more common pattern is:
> + int err;
>
> - setup_irq(TMR_IRQ_NUM, &m68328_timer_irq);
> + err = request_irq(TMR_IRQ_NUM, hw_tick, IRQF_TIMER, "timer", NULL);
> + if (err) {
> + pr_err("timer: request_irq() failed with err=%d\n", err);
> + return err;
> + }
Where the pr_err() could be one of pr_err, printk, dev_err, ...
Regards
Greg
next prev parent reply other threads:[~2020-02-26 2:11 UTC|newest]
Thread overview: 51+ 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: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 10:13 ` Lubomir Rintel
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: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 [this message]
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
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: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 ` [PATCH v2 11/18] s390: replace " afzal mohammed
2020-02-24 0:51 ` [PATCH v2 12/18] sh: " 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-25 2:52 ` kbuild test robot
2020-02-25 7:51 ` afzal mohammed
2020-02-27 10:59 ` [PATCH v3 " afzal mohammed
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 7:10 ` afzal mohammed
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-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=caa5686a-5be3-5848-fdee-36f54237ccb6@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®