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()
    On Thu, 27 Feb 2020, afzal mohammed wrote:

    > 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] ?).
    >

    This isn't new code, so I'd assume it's been "checked" in the sense of
    "reviewed and tested".

    So the lack of an error message could be taken to mean that there's no
    need for an error message.

    If you want to stop the compiler complaining about an unchecked return
    value, assuming that it does so, please consider using

    if (request_irq(...))
    pr_debug(...);

    That way there is no penalty paid for adding error messages that the
    original author apparently did not want.

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