linux-kernel - Re: [PATCH v3 7/7] iio: accel: kx022a: align with subsystem way

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: <a52bce75-c1df-453a-b54e-2dfbeb9c285e@gmail.com>
Date: Mon, 2 Dec 2024 08:46:46 +0200
From: Matti Vaittinen <mazziesaccount@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
 Lars-Peter Clausen <lars@...afoo.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 7/7] iio: accel: kx022a: align with subsystem way

On 30/11/2024 20:26, Jonathan Cameron wrote:
> On Sat, 30 Nov 2024 18:15:06 +0000
> Jonathan Cameron <jic23@...nel.org> wrote:
> 
>> On Thu, 28 Nov 2024 11:03:40 +0200
>> Matti Vaittinen <mazziesaccount@...il.com> wrote:
>>
>>> Many of the Kionix/ROHM accelerometers have a "PC1 - bit" which enables
>>> the accelerometer. While a sensor configuration like ODR, g-range, FIFO
>>> status etc. are changed, the PC1 bit must be cleared (sensor must be
>>> disabled). (See the description for different CNTL registers [1])
>>>
>>> In order to ensure this the kx022a driver uses a mutex, which is locked
>>> when the PC1 bit is cleared, and held for the duration of the
>>> configuration, and released after PC1 bit is set again (enabling the
>>> sensor).
>>>
>>> The locking and PC1 bit toggling was implemented using functions:
>>> kx022a_turn_off_lock() and kx022a_turn_on_unlock().
>>>
>>> Based on a discussions [2], the IIO subsystem prefers open-coding the
>>> locking with scoped_guard() over these functions.
>>>
>>> Drop the kx022a_turn_off_lock() and kx022a_turn_on_unlock() and use
>>> scoped_guard() instead.
>>>
>>> [1]: https://fscdn.rohm.com/kionix/en/datasheet/kx022acr-z-e.pdf
>>> [2]: https://lore.kernel.org/all/20241126175550.4a8bedf3@jic23-huawei/
>>>
>>> Signed-off-by: Matti Vaittinen <mazziesaccount@...il.com>
>>>
>>> ---
>>> Revision history:
>>> v2 => v3:
>>>   - New patch
>>>
>>> NOTE: This patch uses the if_not_cond_guard() which is currently missing
>>> the iio_testing.
>>> https://lore.kernel.org/all/20241001-cleanup-if_not_cond_guard-v1-1-7753810b0f7a@baylibre.com/T/#m69982b23da9f71e72d84855b34e9b142cb3a1920
>>
>> Looks good to me.  If no one else comments, I'll pick this up when
>> I have the precursor available (so hopefully just after rc1)
> or maybe not.
> https://lore.kernel.org/all/CAHk-=whn07tnDosPfn+UcAtWHBcLg=KqA16SHVv0GV4t8P1fHw@mail.gmail.com/
> 
> Seems Linus is unconvinced.
> Hmmm. We might have to roll back the uses of cond_guard() entirely.
> Which will be a pain.  Ah well. Sometimes an idea turns out to not be as useful
> as it initially seemed.
> 46 instances to get rid of in the tree today...

Ouch! :( Sorry to hear Jonathan.

Yours,
	-- Matti