On Tue, Oct 4, 2022 at 4:49 PM Nuno Sá <nuno.sa@xxxxxxxxxx> wrote:
>
> The pattern used in this device does not quite fit in the
> iio_device_claim_direct_mode() typical usage. In this case, we want to
> know if we are in buffered mode or not to know if the device is powered
> (buffer mode) or not. And depending on that max30102_get_temp() will
> power on the device if needed. Hence, in order to keep the same
> functionality, we try to:
>
> 1. Claim Buffered mode;
> 2: If 1) succeeds call max30102_get_temp() without powering on the
> device;
> 3: Release Buffered mode;
> 4: If 1) fails, Claim Direct mode;
> 5: If 4) succeeds call max30102_get_temp() with powering on the device;
> 6: Release Direct mode;
> 7: If 4) fails, goto to 1) and try again.
>
> This dance between buffered and direct mode is not particularly pretty
> (as well as the loop introduced by the goto statement) but it does allow
> us to get rid of the mlock usage while keeping the same behavior.
...
> + if (iio_device_claim_buffer_mode(indio_dev)) {
Why is ret not used here?
> + /*
> + * This one is a *bit* hacky. If we cannot claim buffer
> + * mode, then try direct mode so that we make sure
> + * things cannot concurrently change. And we just keep
> + * trying until we get one of the modes...
> + */
> + if (iio_device_claim_direct_mode(indio_dev))
...and here?
> + goto any_mode_retry;
> + } else {
> + }
I.o.w. what error code will be visible to the caller and why.
--
With Best Regards,
Andy Shevchenko
