From: Greg Ungerer <gerg@linux-m68k.org>
To: afzal mohammed <afzal.mohd.ma@gmail.com>,
Finn Thain <fthain@telegraphics.com.au>
Cc: 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: Fri, 28 Feb 2020 17:05:36 +1000 [thread overview]
Message-ID: <2c8b836e-36f7-e479-db7a-6bb3c072116a@linux-m68k.org> (raw)
In-Reply-To: <20200227081805.GA5746@afzalpc>
Hi Afzal,
On 27/2/20 6:18 pm, afzal mohammed wrote:
> On Wed, Feb 26, 2020 at 10:42:00AM +1000, Greg Ungerer wrote:
>
>>> - 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");
>
> The reason to use %s was that it could be automated by cocci script &
> the o/p didn't look bad. Second arg to pr_err is what cocci
> presents me & there is wide variation in the name across the tree as
> Finn noted.
>
> Excerpts from v1 cover letter [1],
>
> - setup_irq(E1,&act);
> + if (request_irq(E1,f_handler,f_flags,f_name,f_dev_id))
> + pr_err("request_irq() on %s failed\n", f_name);
>
> [ don't get mislead by string contents used, this was for v1, just to
> show how the result was obtained. To take care of Finn's suggesstion,
> instead of modifying cocci & then making changes other changes over
> that (i could not fully automate w/ cocci, and Julia said my script
> is fine as is), it was easier to run sed over the v1 patches ]
>
>> And maybe would it be useful to print out the error return code from a
>> failed request_irq()?
>
> Since most of the existing setup_irq() didn't even check & handle
> error return, my first thought was just s/setup_irq/request_irq, it
> was easier from scripting pointing of view. i felt uncomfortable doing
> nothing in case of error. Also noted that request_irq() definition has
> a "__much_check", so decided to add it.
>
> And there is a wide variation in the way return value is handled by
> the caller, some already have a local variable, some don't. Moreover
> in many cases caller cannot return any value, i.e. void, so what
> to be done with return value was another issue, in some cases in
> addition to printing error value, the error value can't be returned,
> while some others it can.
>
>> What about displaying the requested IRQ number as well?
>> Just a thought.
>
> i initially did the cocci to display IRQ number as the 3rd arg to
> pr_err, but then it was observed that most of the those lines were
> exceeding 80 chars, though cocci could align args properly in next
> line, it could not put flower braces to the preceeding
> 'if request_irq()' & in next line (though it is a single C statement
> inside 'if', per kernel coding style, flower brace had to be put for a
> single statement that spans multiple lines ], else it had to be
> manually added treewide.
>
> On Wed, Feb 26, 2020 at 12:11:55PM +1100, Finn Thain wrote:
>
>> 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.
>>
>> And arguably, the former example is actually the change that's described
>> in the commit description.
>>
>> This patch seems to be making two orthogonal changes but I'll leave that
>> question to the maintainer. (I'm not really trying to NAK this patch.)
>
> Instead of not checking the error value as in the existing cases &
> mechanically replace w/ request_irq(), thought of at least giving user
> the indication by way of pr_err (but i think most of the use is for
> tick timer, if it fails, in most cases, system would not even boot)
> due to the reasons mentioned above.
>
> On Wed, Feb 26, 2020 at 12:11:38PM +1000, Greg Ungerer wrote:
>
>> 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;
>>> + }
>
> This is my preferred style, but note that returning error is not
> possible in many of these cases as callers are void return type.
>
> On Wed, Feb 26, 2020 at 05:39:57PM +1100, Finn Thain wrote:
>
>> Besides, introducing local variables and altering control flow seems well
>> out-of-scope for this kind of refactoring, right?
>
> To make changes perfect, it would be required to get into context of
> each case (>150), and do it manually as there is wide variation like
> whether caller can return error code, whether already a local integer
> is defined to catch the error, whether it returns error after a goto,
> whether we should allow it to proceed if it fails and so on.
>
> And handling manually all the cases tree wide would be more error
> prone & time consuming. i was relieved that there was only one build
> error reported by test robot (i had done build & boot test only on ARM
> & x86_64), given the amount of manual changes i had to do on top of
> cocci generated ones.
>
> At the same time, i didn't want to just mechanically replace & wanted
> to add some value to the existing setup, which resulted in this patch.
>
> My thought process was to do treewide removal of setup_irq() and
> possibly low hanging cleanup's at the places where setup_irq() lives
> to make sure that surrounding situation will be better than or at
> least equal to the current.
Ok, makes sense. Given the very large tree-wide change I can see
why you wanted to completely automate it.
> But if the consensus is that all these situations have to be taken
> care, let me know.
>
> On Wed, Feb 26, 2020 at 10:26:55PM +1000, Greg Ungerer wrote:
>
>> A quick grep shows
>> that "%s: request_irq() failed\n" has no other exact matches in the current
>> kernel source.
>
> git grep -n '%s: request_irq' gives a few somewhat similar ones, i
> remember it because searching this string after my changes to verify
> gave more than that i added :)
Unfortunately similar strings won't be coalesced...
Regards
Greg
next prev parent reply other threads:[~2020-02-28 7:05 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
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 [this message]
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=2c8b836e-36f7-e479-db7a-6bb3c072116a@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;
as well as URLs for NNTP newsgroup(s).