On 26/10/2021 17:10, Arnd Bergmann wrote: > On Wed, Sep 1, 2021 at 2:35 PM Jackie Liu <liu.yun@xxxxxxxxx> wrote: > >> + /* For platform based machines, neither ERR nor NULL can happen here. >> + * The s3c24xx_handle_irq() will be set as IRQ handler iff this succeeds: >> + * >> + * s3c_intc[0] = s3c24xx_init_intc() >> + * >> + * If this fails, the next calls to s3c24xx_init_intc() won't be executed. >> + * >> + * For DT machine, s3c_init_intc_of() could set the IRQ handler without >> + * setting s3c_intc[0] only if it was called with num_ctrl=0. There is no >> + * such code path, so again the s3c_intc[0] will have a valid pointer if >> + * set_handle_irq() is called. >> + * >> + * Therefore in s3c24xx_handle_irq(), the s3c_intc[0] is always something. >> + */ >> + if (s3c24xx_handle_intc(s3c_intc[0], regs, 0)) >> + continue; >> >> - if (s3c_intc[2]) >> + if (!IS_ERR_OR_NULL(s3c_intc[2])) >> if (s3c24xx_handle_intc(s3c_intc[2], regs, 64)) >> continue; > > I just saw this in the pull request. I'm taking the pull request since > it's a bugfix and > the resulting code is technically correct, but I'd point out that this > is particularly > ugly. Any use of IS_ERR_OR_NULL() essentially means we have a misdefined > interface, and it's clear that this is one of them. Yes, that's the case. > > Nothing actually uses the return code of s3c24xx_init_intc(), so returning > NULL on error there and changing all the checks to that would be a much > more straightforward solution. > > Any chance you could send a follow-up to do that? I can work on this but you know this is a legacy platform and none of us can test it? Best regards, Krzysztof
