linux-kernel - Re: [PATCH v2 5/6] gpio: max77759: add Maxim MAX77759 gpio driver

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: <d06058296a194a4f2c9fcbcc5c24816ecb1f51b1.camel@linaro.org>
Date: Fri, 28 Feb 2025 10:58:36 +0000
From: André Draszik <andre.draszik@...aro.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Bartosz
 Golaszewski <brgl@...ev.pl>,  Srinivas Kandagatla
 <srinivas.kandagatla@...aro.org>, Kees Cook <kees@...nel.org>, "Gustavo A.
 R. Silva"	 <gustavoars@...nel.org>, Peter Griffin
 <peter.griffin@...aro.org>, Tudor Ambarus <tudor.ambarus@...aro.org>, Will
 McVicker <willmcvicker@...gle.com>, 	kernel-team@...roid.com,
 linux-kernel@...r.kernel.org, 	devicetree@...r.kernel.org,
 linux-gpio@...r.kernel.org, 	linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2 5/6] gpio: max77759: add Maxim MAX77759 gpio driver

Hi Linus,

Thanks for you review!

On Fri, 2025-02-28 at 08:10 +0100, Linus Walleij wrote:
> Hi André,
> 
> thanks for your patch!
> 
> mostly looks fine, given the MFD design is accepted.
> Nitpicks below:
> 
> On Wed, Feb 26, 2025 at 6:51 PM André Draszik <andre.draszik@...aro.org> wrote:
> 
> > +static irqreturn_t max77759_gpio_irqhandler(int irq, void *data)
> > +{
> > +       int handled = 0;
> 
> bool handled = false;
> 
> (...)
> > +               for_each_set_bit(offset, &pending, MAX77759_N_GPIOS) {
> > +                       unsigned int virq;
> 
> I usually just call this "irq", as it's not any more virtual than any other
> Linux magic number, and it can confuse people working with
> actual virtualization when we call things virtual like this.

Calling it 'irq' would shadow the first argument of this irq
handler function, which is also and usually called irq and which
I'd like to avoid shadowing.

Are you OK with 'subirq'? Or any other preference?

Cheers,
Andre'