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] [thread-next>] [day] [month] [year] [list]
Message-Id: <DF96UPJ1TKP2.2U8D76HGLPT09@gmail.com>
Date: Sat, 27 Dec 2025 12:51:39 -0500
From: "Kurt Borja" <kuurtb@...il.com>
To: "David Lechner" <dlechner@...libre.com>, "Kurt Borja"
 <kuurtb@...il.com>, "Andy Shevchenko" <andriy.shevchenko@...el.com>,
 "Lars-Peter Clausen" <lars@...afoo.de>, "Michael Hennerich"
 <Michael.Hennerich@...log.com>, "Jonathan Cameron" <jic23@...nel.org>,
 "Benson Leung" <bleung@...omium.org>, "Antoniu Miclaus"
 <antoniu.miclaus@...log.com>, "Gwendal Grignou" <gwendal@...omium.org>,
 "Shrikant Raskar" <raskar.shree97@...il.com>, "Per-Daniel Olsson"
 <perdaniel.olsson@...s.com>
Cc: Nuno Sá <nuno.sa@...log.com>, "Andy Shevchenko"
 <andy@...nel.org>, "Guenter Roeck" <groeck@...omium.org>, "Jonathan
 Cameron" <Jonathan.Cameron@...wei.com>, <linux-iio@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <chrome-platform@...ts.linux.dev>
Subject: Re: [PATCH v2 1/7] iio: core: Add and export __iio_dev_mode_lock()

Hi David,

On Tue Dec 23, 2025 at 12:19 PM -05, David Lechner wrote:
> On 12/11/25 8:45 PM, Kurt Borja wrote:
>> Add infallible wrappers around the internal IIO mode lock.
>
> Not sure what "infallible" is supposed to mean in this context. Maybe
> referring to autocleanup?

I meant wrappers that do not fail i.e. return void. Should I word it
differently?

>
>> 
>> As mentioned in the documentation, this is not meant to be used by
>> drivers, instead this will aid in the eventual addition of cleanup
>> classes around conditional locks.
>> 
>> Signed-off-by: Kurt Borja <kuurtb@...il.com>
>> ---
>>  drivers/iio/industrialio-core.c | 30 ++++++++++++++++++++++++++++++
>>  include/linux/iio/iio.h         |  3 +++
>>  2 files changed, 33 insertions(+)
>> 
>> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
>> index f69deefcfb6f..1cce2d1ecef1 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -2171,6 +2171,36 @@ int __devm_iio_device_register(struct device *dev, struct iio_dev *indio_dev,
>>  }
>>  EXPORT_SYMBOL_GPL(__devm_iio_device_register);
>>  
>> +/**
>> + * __iio_dev_mode_lock - Locks the current IIO device mode
>> + * @indio_dev: the iio_dev associated with the device
>> + *
>> + * If the device is either in direct or buffer mode, it's guaranteed to stay
>> + * that way until __iio_dev_mode_unlock() is called.
>> + *
>> + * This function is not meant to be used directly by drivers to protect internal
>> + * state, a driver should have it's own mechanisms for that matter.
>> + *
>> + * There are very few cases where a driver actually needs to lock any mode. It's
>> + * *strongly* recommended to use iio_device_claim_direct() or
>
> I wouldn't even say "strongly recommend". Just say "use these instead".
>
> In the exceptions, likely the autocleanup version should be used as is
> the case currently.

Sure!

-- 
 ~ Kurt

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ