lkml.org 
[lkml]   [2020]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 06/18] m68k: Replace setup_irq() by request_irq()
Hi Geert,

On Thu, Feb 27, 2020 at 09:32:46AM +0100, Geert Uytterhoeven wrote:
> On Thu, Feb 27, 2020 at 9:18 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:

> > 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.
>
> Most (all?) of the code calling setup_irq() is very old, and most of the calls
> happen very early, so any such failures are hard failures that prevent the
> system from booting at all. Hence printing a message may be futile, as it
> may happen before the console has been initialized (modulo early-printk).

The main reason to at least acknowledge the return value was due to
__much_check in request_irq() definition, though w/ the compiler that
i used, there were no warnings, i feared that it might warn w/
some other compilers & in some cases (may be W=[1-3] ?).

Also as most are tick timers, if request_irq() fails, system would die
in that case. But i have seen (iirc in MIPS), in the same execution
sequence multiple setup_irq() invocations, so every instance might not
be unavoidable for system boot.

For tick timer cases, a BUG() might be suitable, but i didn't even
think of that option as that is a recipe for getting trashed from head
penguin (though he would not care trivial patches like this), same
scenario w/ adding warnings.

> Just my 2 €c.

That is my 2 paise, but per exchange rate it will be far less ;)

Regards
afzal

\
 
 \ /
  Last update: 2020-02-27 13:06    [W:0.135 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site