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: <ZfLYGL/vXMHUGghz@vamoirid-EDL-PC>
Date: Thu, 14 Mar 2024 11:57:28 +0100
From: vamoirid <vassilisamir@...il.com>
To: Vasileios Amoiridis <vassilisamir@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, jic23@...nel.org,
	lars@...afoo.de, ang.iglesiasg@...il.com, mazziesaccount@...il.com,
	ak@...klinger.de, petre.rodan@...dimension.ro,
	linus.walleij@...aro.org, phil@...pberrypi.com, 579lpy@...il.com,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/6] iio: pressure: add SCALE and RAW values for
 channels

On Wed, Mar 13, 2024 at 10:28:12PM +0100, Vasileios Amoiridis wrote:
> On Wed, Mar 13, 2024 at 10:04:05PM +0200, Andy Shevchenko wrote:
> > On Wed, Mar 13, 2024 at 08:51:10PM +0100, Vasileios Amoiridis wrote:
> > > On Wed, Mar 13, 2024 at 09:03:08PM +0200, Andy Shevchenko wrote:
> > > > On Wed, Mar 13, 2024 at 06:40:04PM +0100, Vasileios Amoiridis wrote:
> > > > > Add extra IIO_CHAN_INFO_SCALE and IIO_CHAN_INFO_RAW in order to be
> > > > > able to calculate the processed value with standard userspace IIO
> > > > > tools. Can be used for triggered buffers as well.
> > 
> > ...
> > 
> > > > > +	case IIO_CHAN_INFO_RAW:
> > > > > +		switch (chan->type) {
> > > > > +		case IIO_HUMIDITYRELATIVE:
> > > > > +			*val = data->chip_info->read_humid(data);
> > > > > +			ret = IIO_VAL_INT;
> > > > > +			break;
> > > > > +		case IIO_PRESSURE:
> > > > > +			*val = data->chip_info->read_press(data);
> > > > > +			ret = IIO_VAL_INT;
> > > > > +			break;
> > > > > +		case IIO_TEMP:
> > > > > +			*val = data->chip_info->read_temp(data);
> > > > > +			ret = IIO_VAL_INT;
> > > > > +			break;
> > > > > +		default:
> > > > > +			ret = -EINVAL;
> > > > > +			break;
> > > > 
> > > > Is it mutex that prevents us from returning here?
> > > > If so, perhaps switching to use cleanup.h first?
> > > 
> > > I haven't seen cleanup.h used in any file and now that I searched,
> > > only 5-6 are including it.
> > 
> > Hmm... Which repository you are checking with?
> > 
> > $ git grep -lw cleanup.h -- drivers/ | wc -l
> > 47
> > 
> > (Today's Linux Next)
> >
> 
> I am checking the drivers/iio of 6.8 (on sunday) and I can only find 7
> drivers that use it.
> 
> > > I am currently thinking if the mutex
> > > that already exists is really needed since most of the drivers
> > > don't have it + I feel like this is something that should be done
> > > by IIO, thus maybe it's not even needed here.
> >

After some researching today, I realized that all the                           
{read/write}_{raw/avail}_{multi/}() functions are in drivers/iio/inkern.c
for channel mapping in the kernel and it looks like they are guarded by
the mutex_{un}lock(&iio_dev_opaque->info_exist_lock). So I feel that the
mutexes in the aforementioned functions can be dropped. When you have the
time please have a look, maybe the could be dropped.

In general, there is quite some cleaning that can be done in this driver
but is it wise to include it in the triggered buffer support series??? I
have noticed quite some things that could be improved but I am hesitating
to do it now in order to not "pollute" this series with many cleanups and
leave it for another cleanup series for example.

Best regards,
Vasilis Amoiridis

> > > > > +		}
> > > > > +		break;
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko
> > 
> > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ