Re: [PATCH 2/3] iio: filter: admv8818: Simplify locking with guard()

[Ethan Tidmore]

On Fri Feb 27, 2026 at 10:08 AM CST, David Lechner wrote:
> On 2/27/26 12:14 AM, Ethan Tidmore wrote:
>> Use guard() instead of manual locking to simplify code.
>> 
>> Signed-off-by: Ethan Tidmore <ethantidmore06@xxxxxxxxx>
>> ---
>
>
>> @@ -352,13 +344,8 @@ static int __admv8818_read_hpf_freq(struct admv8818_state *st, u64 *hpf_freq)
>>  
>>  static int admv8818_read_hpf_freq(struct admv8818_state *st, u64 *hpf_freq)
>>  {
>> -	int ret;
>> -
>> -	mutex_lock(&st->lock);
>> -	ret = __admv8818_read_hpf_freq(st, hpf_freq);
>> -	mutex_unlock(&st->lock);
>> -
>> -	return ret;
>> +	guard(mutex)(&st->lock);
>> +	return __admv8818_read_hpf_freq(st, hpf_freq);
>>  }
>
> admv8818_read_hpf_freq() is the only caller of __admv8818_read_hpf_freq()
> so we can drop the wrapper, move the guard to __admv8818_read_hpf_freq()
> and rename it to admv8818_read_hpf_freq().
>
> I didn't check all functions, but might be others places where we can do
> this as well.

So this can be easily done with a few wrappers but these two functions
have this odd scenario:

	guard(mutex)(&st->lock);

	ret = __admv8818_hpf_select(st, hpf_corner_target);
	if (ret)
		return ret;

	return __admv8818_lpf_select(st, lpf_corner_target);

Where if I deleted that guard() and just made those hold the lock
separately this would be a behaviour change. Wondering if there was a
nice way to get around this?

Thanks,

ET