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

[Matti Vaittinen <mazziesaccount@gmail.com>]

On 30/11/2024 20:26, Jonathan Cameron wrote:
> On Sat, 30 Nov 2024 18:15:06 +0000
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
>> On Thu, 28 Nov 2024 11:03:40 +0200
>> Matti Vaittinen <mazziesaccount@gmail.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@gmail.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