linux-kernel - Re: [PATCH v3 16/28] staging: iio: tsl2583: updated code comment to match what the code does

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Nov 2016 17:10:07 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     Brian Masney <masneyb@...tation.org>
Cc:     linux-iio@...r.kernel.org, devel@...verdev.osuosl.org,
        gregkh@...uxfoundation.org, lars@...afoo.de, pmeerw@...erw.net,
        knaack.h@....de, linux-kernel@...r.kernel.org, Jon.Brenner@....com
Subject: Re: [PATCH v3 16/28] staging: iio: tsl2583: updated code comment to
 match what the code does

On 12/11/16 16:59, Brian Masney wrote:
> On Sat, Nov 12, 2016 at 04:36:37PM +0000, Jonathan Cameron wrote:
>> On 10/11/16 09:25, Brian Masney wrote:
>>> If channel 0 does not have any data, then the code sets the lux to zero.
>>> The corresponding comment says that the last value is returned. This
>>> updates the comment to correctly reflect what the code does.
>>>
>>> Signed-off-by: Brian Masney <masneyb@...tation.org>
>> Better perhaps to just return an error, -EAGAIN perhaps?
>> I'm not sure why it would not give a value.
> 
> This check is to avoid a division by zero. Here is the relevant code
> that wasn't shown in the diff:
> 
> 	if (!ch0) {
> 		/* have no data, so return 0 */
> 		ret = 0;
> 		chip->als_cur_info.lux = 0;
> 		goto done;
> 	}
> 
> 	/* calculate ratio */
> 	ratio = (ch1 << 15) / ch0;
> 
> Channel 0 is sensitive to both infrared and visible light. In total
> darkness, the sensor should return 0. Correct me if I am wrong, but
> I believe that returning 0 here is more correct than -EAGAIN.
> 
> Brian
> 
Fair enough I hadn't understood that.  Maybe expand the comment
to cover that?