Messages in this thread | | | Date | Thu, 27 Feb 2020 17:36:18 +0530 | From | afzal mohammed <> | Subject | Re: [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
| |