linux-kernel - Re: [PATCH v4 1/9] i2c: riic: Introduce a separate variable for IRQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+V-a8tH9TA9MWGiVOKXjt8hJKM7McfQ6iOpA_WpYKkn_vTVaQ@mail.gmail.com>
Date: Fri, 3 Jan 2025 12:21:54 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Chris Brandt <chris.brandt@...esas.com>, Andi Shyti <andi.shyti@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Andy Shevchenko <andy.shevchenko@...il.com>, Philipp Zabel <p.zabel@...gutronix.de>, 
	linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v4 1/9] i2c: riic: Introduce a separate variable for IRQ

Hi Geert,

Thank you for the review.

On Fri, Jan 3, 2025 at 10:48 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> Thanks for your patch!
>
> On Fri, Jan 3, 2025 at 10:19 AM Prabhakar <prabhakar.csengg@...il.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Refactor the IRQ handling in riic_i2c_probe by introducing a local variable
> > `irq` to store IRQ numbers instead of assigning them to `ret`. This change
> > improves code readability and clarity.
> >
> > Remove explicit error handling after `platform_get_irq()` since
> > `devm_request_irq()` already handles such errors.
>
> Where does it handle such errors?
> I only found the following check in request_threaded_irq():
>
>         desc = irq_to_desc(irq);
>         if (!desc)
>                 return -EINVAL;
>
> Although irq_to_desc() takes an unsigned int, it should indeed catch
> invalid (negative) interrupt numbers, but the code above would not
> propagate the correct error code (e.g. -EPROBE_DEFER).
>
Agreed, I had missed that. I will restore the check.

Cheers,
Prabhakar