On 19/02/2025 17:25, David Lechner wrote:
On 2/19/25 6:21 AM, Matti Vaittinen 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@xxxxxxxxxx>
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@xxxxxxxxxx>
Cc: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
---
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@xxxxxxxxx>
Yours,
-- Matti
Would a name like iio_device_try_claim_direct_mode() make it more
obvious that it returned a bool instead of int?
In general? I don't know. For me ... I am afraid I wouldn't have guessed
the type of the return value (or 0 == "failure to claim direct") even
with such name. It's still fair to say that I do _really_ rarely use
stuff like mutex_trylock(), so I can't say if different naming would
help someone else who uses those variants more.
What I would expect is -EBUSY when claiming fails, 0 if it succeeds :)
If this won't work for what ever reasons, then I'll just live with this
function using bool and returning true on success, and move on ;)
Yours,
-- Matti
