linux-kernel - Re: [PATCH v5 5/5] iio: amplifiers: hmc425a: add support for LTC6373 Instrumentation Amplifier

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] [day] [month] [year] [list]

Date: Mon, 26 Feb 2024 09:25:59 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Dumitru Ceclan <mitrutzceclan@...il.com>, Lars-Peter Clausen
	 <lars@...afoo.de>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
	 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-iio@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Ceclan Dumitru <dumitru.ceclan@...log.com>
Subject: Re: [PATCH v5 5/5] iio: amplifiers: hmc425a: add support for
 LTC6373 Instrumentation Amplifier

On Sat, 2024-02-24 at 17:54 +0000, Jonathan Cameron wrote:
> On Wed, 21 Feb 2024 14:23:51 +0100
> Nuno Sá <noname.nuno@...il.com> wrote:
> 
> > On Tue, 2024-02-20 at 17:34 +0200, Dumitru Ceclan wrote:
> > > This adds support for LTC6373 36 V Fully-Differential Programmable-Gain
> > > Instrumentation Amplifier with 25 pA Input Bias Current.
> > > The user can program the gain to one of seven available settings through
> > > a 3-bit parallel interface (A2 to A0).
> > > 
> > > Signed-off-by: Dumitru Ceclan <mitrutzceclan@...il.com>
> > > ---  
> > 
> > Just one minor comment. With that:
> > 
> > Reviewed-by: Nuno Sa <nuno.sa@...log.com>
> > 
> > >  drivers/iio/amplifiers/hmc425a.c | 124 ++++++++++++++++++++++++++++++-
> > >  1 file changed, 120 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/iio/amplifiers/hmc425a.c
> > > b/drivers/iio/amplifiers/hmc425a.c
> > > index 77872e2dfdfe..50c86c2d28d7 100644
> > > --- a/drivers/iio/amplifiers/hmc425a.c
> > > +++ b/drivers/iio/amplifiers/hmc425a.c
> > > @@ -2,9 +2,10 @@
> > >  /*
> > >   * HMC425A and similar Gain Amplifiers
> > >   *
> > > - * Copyright 2020 Analog Devices Inc.
> > > + * Copyright 2020, 2024 Analog Devices Inc.
> > >   */  
> > 
> > ...
> > 
> > > 
> > >  
> > > +static ssize_t ltc6373_read_powerdown(struct iio_dev *indio_dev,
> > > +				      uintptr_t private,
> > > +				      const struct iio_chan_spec *chan,
> > > +				      char *buf)
> > > +{
> > > +	struct hmc425a_state *st = iio_priv(indio_dev);
> > > +
> > > +	return sysfs_emit(buf, "%d\n", st->powerdown);  
> > 
> > Well, in theory the read should also be protected with the lock...
> 
> Only reason I can think of for that is potential read tearing.
> If that happens on a bool we are going to be in a mess so I think this
> is in practice fine without, though paranoia might suggest locking.

Yeah, also mentioned it for correctness. I mean, in theory, read_once() should be
more that enough in here but I often find that too much for using in "simple" drivers
where a lock is surely easier to understand for someone reading the code.

Now, about your bool comment, I used to think like that until I saw the LF rcu
mentorship video from Paul. I'm fairly sure he comes up with some "crazy" possibility
about the CPU/compiler screwing you even on a char (IIRC, he was also arguing about
not using read_once() on a bool).

Now, practically speaking, I tend to agree that for the archs we care this will
likely never be an issue but yeah, not 100% correct kernel code IMO.

- Nuno Sá