2016-11-30 11:10 GMT+01:00 Lars-Peter Clausen <l...@metafoo.de>:
> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <l...@metafoo.de>:
>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> new file mode 100644
>>>> index 0000000..147458f
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>> @@ -0,0 +1,18 @@
>>>> +Industrial IO regulator device driver
>>>> +This document describes the bindings for the iio-regulator - a dummy
>>>> +driver representing a physical regulator within the iio framework.
>>> No bindings for drivers, only for hardware. So this wont work.
>> What about exporting regulator attributes analogous to the one in this
>> patch from the iio-core when a *-supply property is specified for a
> The problem with exposing direct control to the regulator is that it allows
> to modify the hardware state without the drivers knowledge. If you
> power-cycle a device all previous configuration that has been written to the
> device is reset. The device driver needs to be aware of this otherwise its
> assumed state and the actual device state can divert which will result in
> undefined behavior. Also access to the device will fail unexpectedly when
> the regulator is turned off. So I think generally the driver should
> explicitly control the regulator, power-up when needed, power-down when not.
> - Lars
I missed the fact that - unlike hwmon - the iio version of the ina2xx
driver is not capable of detecting a bad state and re-initializing
itself. But you're right in general of course.
Still, it made me think: what if we implement the suspend/resume
callbacks in struct device_driver to store/resume the state when
power-cycling? The core iio module would then call the suspend
callback before disabling the regulator. We wouldn't need to duplicate
similar code and DT bindings in every iio driver.