Re: [PATCH v8 5/5] iio: light: Add support for APDS9306 Light Sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 2/29/24 15:42, Andy Shevchenko wrote:
On Thu, Feb 29, 2024 at 02:58:52PM +0200, Matti Vaittinen wrote:
On 2/29/24 14:34, Subhajit Ghosh wrote:
On 29/2/24 03:57, Andy Shevchenko wrote:
On Wed, Feb 28, 2024 at 03:08:56PM +0200, Matti Vaittinen wrote:
On 2/28/24 14:24, Subhajit Ghosh wrote:


+    if (gain_new < 0) {
+        dev_err_ratelimited(dev, "Unsupported gain with time\n");
+        return gain_new;
+    }

What is the difference between negative response from the function
itself and
similar in gain_new?

-ve response form the function is an error condition.
-ve value in gain_new means - no valid gains could be computed.
In case of error conditions from the function, the gain_new is also set
to -1.
My use case is valid hardware gain so I went for checking only gain_new.
Matti will be the best person to answer on this.

I now rely on the kerneldoc for the
iio_gts_find_new_gain_by_old_gain_time() as it seems reasonable to me:

* Return: 0 if an exactly matching supported new gain was found. When a
* non-zero value is returned, the @new_gain will be set to a negative or
* positive value. The negative value means that no gain could be computed.
* Positive value will be the "best possible new gain there could be". There
* can be two reasons why finding the "best possible" new gain is not deemed
* successful. 1) This new value cannot be supported by the hardware. 2) The
* gain required to maintain the scale would not be an integer. In this case,
* the "best possible" new gain will be a floored optimal gain, which may or
* may not be supported by the hardware.

Eg, if ret is zero, there is no need to check validity of the gain_new but
it is guaranteed to be one of the supported gains.

Right, but this kernel doc despite being so verbose does not fully answer my
question. What is the semantic of that "negative value"?

Current approach is to always investigate the function return value as error if the 'new_gain' is negative. Or, caller specific error if new_gain is unsuitable in some other way. When this is done, the absolute value of the negative 'new_gain' does not matter.

I would expect to have
the error code there (maybe different to what the function returns), but at
least be able to return it to the upper layers if needed.

I am not sure I see the benefit of returning the new_gain over returning the error returned by the function. Well, maybe the benefit to be able to not evaluate the value returned by the iio_gts_find_new_gain_by_old_gain_time() - although I'm not sure I love it.

Hence 2 ARs I see:
1) clarify the kernel documentation there;
2) update the semantic of the gain_new to simplify caller's code.

Yes, I agree. Patches welcome :) By the very least the kerneldoc can be improved. I'm undecided on benefits of having the error code in 'new_gain'.

The GTS API fixes shouldn't be required in the context of this driver series though.


Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     []

  Powered by Linux