linux-kernel - Re: [PATCH v2 9/9] iio: adc: ad4062: Add GPIO Controller support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aSgX9nMBwBtAlSyj@smile.fi.intel.com>
Date: Thu, 27 Nov 2025 11:20:54 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Jorge Marques <gastmaier@...il.com>
Cc: Jorge Marques <jorge.marques@...log.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	Linus Walleij <linus.walleij@...aro.org>,
	Bartosz Golaszewski <brgl@...ev.pl>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-gpio@...r.kernel.org
Subject: Re: [PATCH v2 9/9] iio: adc: ad4062: Add GPIO Controller support

On Wed, Nov 26, 2025 at 04:55:41PM +0100, Jorge Marques wrote:
> On Mon, Nov 24, 2025 at 12:40:37PM +0200, Andy Shevchenko wrote:
> > On Mon, Nov 24, 2025 at 10:18:08AM +0100, Jorge Marques wrote:

...

> > Why can't gpio-regmap be used?
> > 
> Because the device register values (0x5, 0x6) does not fit the gpio-regmap.
> It writes the mask for high and 0 for low.
> But low is 01[01] and
>     high   01[10]
> 
> A different series would need to extend the gpio-regmap ops, but if you
> implement your custom reg read/write, then you save at most ~5 lines...
> I will add that to the commit message.

OK.

...

> > > +	return reg_val == AD4062_GP_STATIC_HIGH ? 1 : 0;
> > 
> > 	return !!(reg_val == AD4062_GP_STATIC_HIGH);
> > 
> > also will work.
> >
>  	return reg_val == AD4062_GP_STATIC_HIGH;

Hmm... This will include implicit bool->int. The !! guarantees values 0 or 1,
but I don't remember about implicit bool->int case.

...

> > > +static int ad4062_gpio_init_valid_mask(struct gpio_chip *gc,
> > > +				       unsigned long *valid_mask,
> > > +				       unsigned int ngpios)
> > > +{
> > > +	struct ad4062_state *st = gpiochip_get_data(gc);
> > > +
> > > +	bitmap_zero(valid_mask, ngpios);
> > > +
> > > +	if (!st->gpo_irq[0])
> > > +		set_bit(0, valid_mask);
> > > +	if (!st->gpo_irq[1])
> > > +		set_bit(1, valid_mask);
> > 
> > Why atomic bit set:s?
> > 
> Not needed, will use

Note, bitops are xxx_bit() -- atomic, __xxx_bit() -- non-atomic,
that's what I had in mind.

> 	if (!st->gpo_irq[0])
> 		*valid_mask |= BIT(0);
> 	if (!st->gpo_irq[1])
> 		*valid_mask |= BIT(1);

Can't it be rather something like

	for (unsigned int i = 0; i < ...; i++)
		__assign_bit(i, valid_mask, st->gpo_irq[i]);

?
This shorter and does the same independently on the length of the bitmask
(and effectively the array size of gpo_irq)

> > > +	return 0;
> > > +}

-- 
With Best Regards,
Andy Shevchenko