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@xxxxxxxxx> 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
