linux-kernel - Re: [PATCH v1 5/7] iio: adc: ad4170: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z_0XgTYnDXd2x0b9@debian-BULLSEYE-live-builder-AMD64>
Date: Mon, 14 Apr 2025 11:11:13 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Nuno Sá <noname.nuno@...il.com>
Cc: Marcelo Schmitt <marcelo.schmitt@...log.com>, linux-iio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	jic23@...nel.org, lars@...afoo.de, Michael.Hennerich@...log.com,
	dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org
Subject: Re: [PATCH v1 5/7] iio: adc: ad4170: Add GPIO controller support

...
> > +static int ad4170_gpio_get_direction(struct gpio_chip *gc, unsigned int
> > offset)
> > +{
> > +	struct iio_dev *indio_dev = gpiochip_get_data(gc);
> > +	struct ad4170_state *st = iio_priv(indio_dev);
> > +	unsigned int val;
> > +	int ret;
> > +
> > +	if (!iio_device_claim_direct(indio_dev))
> > +		return -EBUSY;
> > +
> 
> This claim_direct() makes me wonder if there's any overlap between the GPIO func
> and normal readings? Like, imagine a consumer requests a gpio and no buffering
> is happening so all is good. However, there's nothing stopping us for enabling
> buffering afterwards, right? Wouldn't that be an issue? If there are shared
> pins, I can see this also being an issue even for single shot reading...
> Otherwise, I wonder why we have this iio_device_claim_direct() calls? Is it just
> for using the internal IIO lock?

We need read/write to AD4170 registers to configure/set/read GPIOs so the intent
of claiming direct mode here is to avoid that from happening while we are doing
something else (e.g. a buffered capture). I'm now considering to also lock on the
state mutex to prevent concurrent run with the single-shot read routine.

Thanks,
Marcelo