linux-kernel - Re: [PATCH 7/9] staging: iio: tsl2583: fix issue with changes to calibscale and int

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 6 Nov 2016 09:23:25 -0500
From:   Brian Masney <masneyb@...tation.org>
To:     Jonathan Cameron <jic23@...nel.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 7/9] staging: iio: tsl2583: fix issue with changes to
 calibscale and int_time not being set on the chip

On Sun, Nov 06, 2016 at 12:03:53PM +0000, Jonathan Cameron wrote:
> On 03/11/16 12:56, Brian Masney wrote:
> > When updating the in_illuminance_calibscale and
> > in_illuminance_integration_time sysfs attributes, these values were not
> > actually written to the chip. The chip would continue to use the old
> > parameters. Extracted out tsl2583_set_als_gain() and
> > tsl2583_set_als_time() functions that are now called when these sysfs
> > attributes are updated. The chip initialization now calls these these
> > new functions.
> > 
> > Rename taos_chip_on() to tsl2583_chip_init() since it is now only called
> > during device probing and when the power management code wakes the
> > device back up. tsl2583_chip_init() was refactored to use the new
> > functions mentioned above.
> > 
> > Previously, the current chip state was represented as a tristate
> > (working, suspended, and unknown). The unknown state was not used. The
> > chip state is now represented with a single boolean value (suspended).
> Last part should probably have been a separate patch.  Earlier stages could
> also have been futher broken up I think to make it easier to review.
> 
> The additional init in the resume path should also protect against suspends
> which actually cut the power to the chip which is nice.
> 
> Just enough bits and pieces inline that I'd like you to do another pass
> on this.

No problem, I'll split this one up for you. My next patch series will
also contain a lot of trivial code cleanups, some documentation updates, and
a request to move the driver out of staging.

The device tree documentation
(Documentation/devicetree/bindings/iio/light/tsl2583.txt) has the
interrupt-parent and interrupts properties as optional, however the
driver does not support interrupts. Should I remove these properties from
the device tree documentation? I can add the code to support the
interrupts but I am hesistant to add that new code if no one will use it.

Brian