Re: [PATCH 5/8] iio: accel: kx022a: Switch to sparse friendly iio_device_claim/release_direct()

[Jonathan Cameron <Jonathan.Cameron@huawei.com>]

On Wed, 19 Feb 2025 14:21:51 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:

> On 19/02/2025 12:51, Nuno Sá wrote:
> > On Wed, 2025-02-19 at 07:36 +0200, Matti Vaittinen wrote:  
> >> On 18/02/2025 17:42, David Lechner wrote:  
> >>> On 2/18/25 1:39 AM, Matti Vaittinen wrote:  
> >>>> On 17/02/2025 16:01, Jonathan Cameron wrote:  
> >>>>> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >>>>>
> >>>>> These new functions allow sparse to find failures to release
> >>>>> direct mode reducing chances of bugs over the claim_direct_mode()
> >>>>> functions that are deprecated.
> >>>>>
> >>>>> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >>>>> Cc: Matti Vaittinen <mazziesaccount@gmail.com>
> >>>>> ---
> >>>>>     drivers/iio/accel/kionix-kx022a.c | 14 ++++++--------
> >>>>>     1 file changed, 6 insertions(+), 8 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/iio/accel/kionix-kx022a.c
> >>>>> b/drivers/iio/accel/kionix-kx022a.c
> >>>>> index 727e007c5fc1..07dcf5f0599f 100644
> >>>>> --- a/drivers/iio/accel/kionix-kx022a.c
> >>>>> +++ b/drivers/iio/accel/kionix-kx022a.c
> >>>>> @@ -577,13 +577,12 @@ static int kx022a_write_raw(struct iio_dev *idev,
> >>>>>          * issues if users trust the watermark to be reached within known
> >>>>>          * time-limit).
> >>>>>          */
> >>>>> -    ret = iio_device_claim_direct_mode(idev);
> >>>>> -    if (ret)
> >>>>> -        return ret;
> >>>>> +    if (!iio_device_claim_direct(idev))
> >>>>> +        return -EBUSY;  
> >>>>
> >>>> Not really in the scope of this review - but in my opinion the logic of
> >>>> this check is terribly counter intuitive. I mean,
> >>>>  
> >>>>> +    if (iio_device_claim_direct(idev))
> >>>>> +        return -EBUSY;  
> >>>
> >>> I'm curious how you read this then. I read this as:
> >>>
> >>> "If claiming direct mode succeeded, then return an error!"  
> >>
> >> I am used to seeing a pattern where function returning zero indicates a
> >> success. I have no statistics but I believe this is true for a vast
> >> majority of functions in the kernel. I believe this was the case with
> >> the old 'iio_device_claim_direct_mode(idev)' too.
> >>  
> > 
> > Fair enough... Note though this is returning a boolean where true makes total
> > sense for the "good" case. I do agree it's not super clear just by reading the
> > code that the API is supposed to return a boolean.  
> 
> Exactly. Just seeing the call in code was not obvious to me. It required 
> finding the prototype to understand what happens.
> 
> Anyways, I guess this discussion is out of the scope of this patch and 
> if no one else sees this important enough to go and change the 
> iio_device_claim_direct() - then I am fine with this patch. So, with a 
> bit of teeth grinding:
> 
> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>

This is copying what happens for the locks that can fail. I agree
that it would have been nice to get the advantages of sparse with
the old interface but from what I recall I got a lot more false positives
so wanted it to look more lock like.

Jonathan

> 
> Yours,
>    -- Matti
> 
>