On 06/11/16 14:23, Brian Masney wrote: > 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. Cool > > 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 > Leave them there. Device tree is about documenting the hardware, not just those bits we get around to using ;) Obviously we have to document what we use but no problem documenting other bits! Jonathan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
