| Message ID | 1480432969-20913-1-git-send-email-bgolaszewski@baylibre.com |
|---|---|
| State | New |
| Headers | show |
On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: [...] > diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device > +driver representing a physical regulator within the iio framework. No bindings for drivers, only for hardware. So this wont work. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: > On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: > [...] >> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >> +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 node? Thanks, Bartosz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: > 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: >> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >> [...] >>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >>> +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 > node? 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-11-30 11:10 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: > On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: >>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >>> [...] >>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >>>> +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 >> node? > > 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. Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30/11/16 10:10, Lars-Peter Clausen wrote: > On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: >>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >>> [...] >>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >>>> +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 >> node? > > 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. I agree with what Lars has said. There 'may' be some argument to ultimately have a bridge driver from regulators to IIO. That would be for cases where the divide between a regulator and a DAC is blurred. However it would still have to play nicely with the regulator framework and any other devices registered on that regulator. Ultimately the ideal in that case would then be to describe what the DAC is actually being used to do but that's a more complex issue! That doesn't seem to be what you are targeting here. What it sounds like you need is to have the hardware well enough described that the standard runtime power management can disable the regulator just fine when it is not in use. This may mean improving the power management in the relevant drivers. Jonathan p.s. If ever proposing to do something 'unusual' with a regulator you should bring in the regulator framework maintainers in the cc list. > > - Lars > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23@kernel.org>: > On 30/11/16 10:10, Lars-Peter Clausen wrote: >> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: >>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >>>> [...] >>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >>>>> +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 >>> node? >> >> 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. > I agree with what Lars has said. > > There 'may' be some argument to ultimately have a bridge driver from > regulators to IIO. That would be for cases where the divide between a regulator > and a DAC is blurred. However it would still have to play nicely with the > regulator framework and any other devices registered on that regulator. > Ultimately the ideal in that case would then be to describe what the DAC is > actually being used to do but that's a more complex issue! > > That doesn't seem to be what you are targeting here. > > What it sounds like you need is to have the hardware well enough described that > the standard runtime power management can disable the regulator just fine when > it is not in use. This may mean improving the power management in the relevant > drivers. > > Jonathan > > p.s. If ever proposing to do something 'unusual' with a regulator you should > bring in the regulator framework maintainers in the cc list. >> >> - Lars >> > I wrote the initial patch quickly and didn't give it much of a thought. Now I realized I completely missed the point and managed to confuse everybody - myself included. So the problem we have is not power-cycling the adc - it's power-cycling the device connected to a probe on which there's an adc. What I was trying to do was adding support for the power-switch on baylibre-acme[1] probes. For example: we have a USB probe on which the VBUS signal goes through a power load switch and than through the adc. The adc (in this case ina226) is always powered on, while the fixed regulator I wanted to enable/disable actually drives the power switch to cut/restore power to the connected USB device i.e. there's no real regulator - just a GPIO driving the power switch. A typical use case is measuring the power consumption of development boards[2]. Rebooting them remotely using acme probes is already done, but we're using the obsolete /sys/class/gpio interface. We're already using libiio to read the measured data from the power monitor, that's why we'd like to use the iio framework for power-cycling the devices as well. My question is: would bridging the regulator framework be the right solution? Should we look for something else? Bridge the GPIO framework instead? Best regards, Bartosz Golaszewski [1] http://baylibre.com/acme/ [2] https://github.com/BayLibre/POWERCI -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/12/16 11:12, Bartosz Golaszewski wrote: > 2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23@kernel.org>: >> On 30/11/16 10:10, Lars-Peter Clausen wrote: >>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote: >>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: >>>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote: >>>>> [...] >>>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device >>>>>> +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 >>>> node? >>> >>> 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. >> I agree with what Lars has said. >> >> There 'may' be some argument to ultimately have a bridge driver from >> regulators to IIO. That would be for cases where the divide between a regulator >> and a DAC is blurred. However it would still have to play nicely with the >> regulator framework and any other devices registered on that regulator. >> Ultimately the ideal in that case would then be to describe what the DAC is >> actually being used to do but that's a more complex issue! >> >> That doesn't seem to be what you are targeting here. >> >> What it sounds like you need is to have the hardware well enough described that >> the standard runtime power management can disable the regulator just fine when >> it is not in use. This may mean improving the power management in the relevant >> drivers. >> >> Jonathan >> >> p.s. If ever proposing to do something 'unusual' with a regulator you should >> bring in the regulator framework maintainers in the cc list. >>> >>> - Lars >>> >> > > I wrote the initial patch quickly and didn't give it much of a > thought. Now I realized I completely missed the point and managed to > confuse everybody - myself included. > > So the problem we have is not power-cycling the adc - it's > power-cycling the device connected to a probe on which there's an adc. > What I was trying to do was adding support for the power-switch on > baylibre-acme[1] probes. > > For example: we have a USB probe on which the VBUS signal goes through > a power load switch and than through the adc. The adc (in this case > ina226) is always powered on, while the fixed regulator I wanted to > enable/disable actually drives the power switch to cut/restore power > to the connected USB device i.e. there's no real regulator - just a > GPIO driving the power switch. > > A typical use case is measuring the power consumption of development > boards[2]. Rebooting them remotely using acme probes is already done, > but we're using the obsolete /sys/class/gpio interface. > > We're already using libiio to read the measured data from the power > monitor, that's why we'd like to use the iio framework for > power-cycling the devices as well. My question is: would bridging the > regulator framework be the right solution? Should we look for > something else? Bridge the GPIO framework instead? Definitely doesn't fit inside standard scope of IIO - though I can see why you were thinking along these lines. Mark Brown, any thoughts? Effectively we are are looking at something that (in general form) might be the equivalent of controlling a lab bench supply... So regulators at the edge of the known world, with no visibility of what lies beyond. > > Best regards, > Bartosz Golaszewski > > [1] http://baylibre.com/acme/ > [2] https://github.com/BayLibre/POWERCI > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-12-10 19:17 GMT+01:00 Jonathan Cameron <jic23@kernel.org>: > On 06/12/16 11:12, Bartosz Golaszewski wrote: >> >> I wrote the initial patch quickly and didn't give it much of a >> thought. Now I realized I completely missed the point and managed to >> confuse everybody - myself included. >> >> So the problem we have is not power-cycling the adc - it's >> power-cycling the device connected to a probe on which there's an adc. >> What I was trying to do was adding support for the power-switch on >> baylibre-acme[1] probes. >> >> For example: we have a USB probe on which the VBUS signal goes through >> a power load switch and than through the adc. The adc (in this case >> ina226) is always powered on, while the fixed regulator I wanted to >> enable/disable actually drives the power switch to cut/restore power >> to the connected USB device i.e. there's no real regulator - just a >> GPIO driving the power switch. >> >> A typical use case is measuring the power consumption of development >> boards[2]. Rebooting them remotely using acme probes is already done, >> but we're using the obsolete /sys/class/gpio interface. >> >> We're already using libiio to read the measured data from the power >> monitor, that's why we'd like to use the iio framework for >> power-cycling the devices as well. My question is: would bridging the >> regulator framework be the right solution? Should we look for >> something else? Bridge the GPIO framework instead? > > Definitely doesn't fit inside standard scope of IIO - though I can see > why you were thinking along these lines. > Well, it's industrial INPUT/output right? I guess we can consider power-cycling input in this case. :) In our particular use case, the main reason for using IIO is having a single interface (libiio) instead of introducing a new one just for that (in the form of random sysfs attributes for example), but I'm sure such power switches could find application elsewhere too (measuring temperature, while power-cycling some cooling mechanism is the first thing that comes to mind). > Mark Brown, any thoughts? > > Effectively we are are looking at something that (in general form) might > be the equivalent of controlling a lab bench supply... So regulators > at the edge of the known world, with no visibility of what lies beyond. > Please consider the two patches I just sent. Instead of regulators, they add DT bindings for gpio power switches and introduce a simple iio driver using the gpio consumer API. Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-12-12 18:15 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>: > On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: [snip!] >> >> So the problem we have is not power-cycling the adc - it's >> power-cycling the device connected to a probe on which there's an adc. >> What I was trying to do was adding support for the power-switch on >> baylibre-acme[1] probes. >> >> For example: we have a USB probe on which the VBUS signal goes through >> a power load switch and than through the adc. The adc (in this case >> ina226) is always powered on, while the fixed regulator I wanted to >> enable/disable actually drives the power switch to cut/restore power >> to the connected USB device i.e. there's no real regulator - just a >> GPIO driving the power switch. >> >> A typical use case is measuring the power consumption of development >> boards[2]. Rebooting them remotely using acme probes is already done, >> but we're using the obsolete /sys/class/gpio interface. >> >> We're already using libiio to read the measured data from the power >> monitor, that's why we'd like to use the iio framework for >> power-cycling the devices as well. My question is: would bridging the >> regulator framework be the right solution? Should we look for >> something else? Bridge the GPIO framework instead? > > I wouldn't necessaries create bridge, but instead just use the GPIO > framework directly. > > We now have the GPIO chardev interface which meant to be used to support > application specific logic that control the GPIOs, but where you don't want > to write a kernel driver. > > My idea was to add GPIOs and GPIO chips as high level object inside libiio > that can be accessed through the same context as the IIO devices. Similar to > the current IIO API you have a API for gpios that allows to enumerate the > GPIO devices and their pins as well as modify the pin state. > + Linus While the new GPIO interface would be very convenient - in our case we could simply name the lines appropriately in the device tree - I'm not sure this would be the correct approach. From this year's ELCE in Berlin I remember Linus suggested during his talk that it's always better to write a kernel driver. Also: this way the relevant GPIO lines would not be reserved for exclusive use by power switches. Linus - do you have any thoughts/suggestions on that subject? Best regards, Bartosz Golaszewski -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lars, On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >> We're already using libiio to read the measured data from the power >> monitor, that's why we'd like to use the iio framework for >> power-cycling the devices as well. My question is: would bridging the >> regulator framework be the right solution? Should we look for >> something else? Bridge the GPIO framework instead? > > I wouldn't necessaries create bridge, but instead just use the GPIO > framework directly. > > We now have the GPIO chardev interface which meant to be used to support > application specific logic that control the GPIOs, but where you don't want > to write a kernel driver. > > My idea was to add GPIOs and GPIO chips as high level object inside libiio > that can be accessed through the same context as the IIO devices. Similar to > the current IIO API you have a API for gpios that allows to enumerate the > GPIO devices and their pins as well as modify the pin state. That would mean libiio has access to all GPIOs, allowing a remote person to not only control through iiod the GPIOs for industrial control, but also the GPIOs not intended for export, right? Having a separate GPIO switch driver avoids that, as DT (or some other means) can be used to specify and label the GPIOs for IIO use. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: > Hi Lars, > > On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >> On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >>> We're already using libiio to read the measured data from the power >>> monitor, that's why we'd like to use the iio framework for >>> power-cycling the devices as well. My question is: would bridging the >>> regulator framework be the right solution? Should we look for >>> something else? Bridge the GPIO framework instead? >> >> I wouldn't necessaries create bridge, but instead just use the GPIO >> framework directly. >> >> We now have the GPIO chardev interface which meant to be used to support >> application specific logic that control the GPIOs, but where you don't want >> to write a kernel driver. >> >> My idea was to add GPIOs and GPIO chips as high level object inside libiio >> that can be accessed through the same context as the IIO devices. Similar to >> the current IIO API you have a API for gpios that allows to enumerate the >> GPIO devices and their pins as well as modify the pin state. > > That would mean libiio has access to all GPIOs, allowing a remote person > to not only control through iiod the GPIOs for industrial control, but also the > GPIOs not intended for export, right? Well, it is a policy question. Who gets access to what. Right now it is all or nothing, a privileged application gets access to all devices/GPIOs, a unprivileged application gets access to nothing. Same for GPIOs as well as IIO devices. iiod at the moment does not have any access control at all, which in itself is a problem. We need to add support for that at some point. I don't see an issue with implementing a finer grained access scheme when we do so. E.g. unprivileged applications only get access to certain pins. > Having a separate GPIO switch driver avoids that, as DT (or some other means) > can be used to specify and label the GPIOs for IIO use. Sure, functionally this would be equivalent, but we have to ask whether this is the right way to use the DT. Is access policy specification part of the hardware description? In my opinion the answer is no. At the hardware description level there is no operating system, there is no userspace or kernelspace, there is are no access levels. Putting the distinction between a switch/regulator that can be controlled from userspace or can only be controlled from kernel space into the DT would be a layering violation. It is analogous to why we don't have spidev DT bindings. This is an issue that needs to be solved at a higher level. In my opinion this level is a cooperation between kernel- and userspace. Kernelspace offering an interface to export a device for userspace access and userspace making use of that interface to request access to a device. In a similar way to how vfio is structured. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lars, On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: >> On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>> On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >>>> We're already using libiio to read the measured data from the power >>>> monitor, that's why we'd like to use the iio framework for >>>> power-cycling the devices as well. My question is: would bridging the >>>> regulator framework be the right solution? Should we look for >>>> something else? Bridge the GPIO framework instead? >>> >>> I wouldn't necessaries create bridge, but instead just use the GPIO >>> framework directly. >>> >>> We now have the GPIO chardev interface which meant to be used to support >>> application specific logic that control the GPIOs, but where you don't want >>> to write a kernel driver. >>> >>> My idea was to add GPIOs and GPIO chips as high level object inside libiio >>> that can be accessed through the same context as the IIO devices. Similar to >>> the current IIO API you have a API for gpios that allows to enumerate the >>> GPIO devices and their pins as well as modify the pin state. >> >> That would mean libiio has access to all GPIOs, allowing a remote person >> to not only control through iiod the GPIOs for industrial control, but also the >> GPIOs not intended for export, right? > > Well, it is a policy question. Who gets access to what. Right now it is all > or nothing, a privileged application gets access to all devices/GPIOs, a > unprivileged application gets access to nothing. Same for GPIOs as well as > IIO devices. > > iiod at the moment does not have any access control at all, which in itself > is a problem. We need to add support for that at some point. I don't see an > issue with implementing a finer grained access scheme when we do so. E.g. > unprivileged applications only get access to certain pins. OK, so that's WIP. >> Having a separate GPIO switch driver avoids that, as DT (or some other means) >> can be used to specify and label the GPIOs for IIO use. > > Sure, functionally this would be equivalent, but we have to ask whether this > is the right way to use the DT. Is access policy specification part of the > hardware description? In my opinion the answer is no. At the hardware > description level there is no operating system, there is no userspace or > kernelspace, there is are no access levels. Putting the distinction between > a switch/regulator that can be controlled from userspace or can only be > controlled from kernel space into the DT would be a layering violation. It > is analogous to why we don't have spidev DT bindings. This is an issue that > needs to be solved at a higher level. In my opinion this level is a > cooperation between kernel- and userspace. Kernelspace offering an interface > to export a device for userspace access and userspace making use of that > interface to request access to a device. In a similar way to how vfio is > structured. I'm not advocating using DT for policy, only for hardware description. We have means (bindings) to describe GPIOs connected to LEDs and switches (incl. their labels), while you can control LEDs through plain GPIO sysfs export or chardev, too. It's just more error prone to use the latter. We do not have bindings to describe GPIOs connected to e.g. relays. Switching external devices (the internals of those devices not described itself in DT, like in an industrial context), sounds more like something to be handled by IIO, doesn't it? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23 December 2016 12:56:11 GMT+00:00, Geert Uytterhoeven <geert@linux-m68k.org> wrote: >Hi Lars, > >On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars@metafoo.de> >wrote: >> On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: >>> On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen ><lars@metafoo.de> wrote: >>>> On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote: >>>>> We're already using libiio to read the measured data from the >power >>>>> monitor, that's why we'd like to use the iio framework for >>>>> power-cycling the devices as well. My question is: would bridging >the >>>>> regulator framework be the right solution? Should we look for >>>>> something else? Bridge the GPIO framework instead? >>>> >>>> I wouldn't necessaries create bridge, but instead just use the GPIO >>>> framework directly. >>>> >>>> We now have the GPIO chardev interface which meant to be used to >support >>>> application specific logic that control the GPIOs, but where you >don't want >>>> to write a kernel driver. >>>> >>>> My idea was to add GPIOs and GPIO chips as high level object inside >libiio >>>> that can be accessed through the same context as the IIO devices. >Similar to >>>> the current IIO API you have a API for gpios that allows to >enumerate the >>>> GPIO devices and their pins as well as modify the pin state. >>> >>> That would mean libiio has access to all GPIOs, allowing a remote >person >>> to not only control through iiod the GPIOs for industrial control, >but also the >>> GPIOs not intended for export, right? >> >> Well, it is a policy question. Who gets access to what. Right now it >is all >> or nothing, a privileged application gets access to all >devices/GPIOs, a >> unprivileged application gets access to nothing. Same for GPIOs as >well as >> IIO devices. >> >> iiod at the moment does not have any access control at all, which in >itself >> is a problem. We need to add support for that at some point. I don't >see an >> issue with implementing a finer grained access scheme when we do so. >E.g. >> unprivileged applications only get access to certain pins. > >OK, so that's WIP. > >>> Having a separate GPIO switch driver avoids that, as DT (or some >other means) >>> can be used to specify and label the GPIOs for IIO use. >> >> Sure, functionally this would be equivalent, but we have to ask >whether this >> is the right way to use the DT. Is access policy specification part >of the >> hardware description? In my opinion the answer is no. At the hardware >> description level there is no operating system, there is no userspace >or >> kernelspace, there is are no access levels. Putting the distinction >between >> a switch/regulator that can be controlled from userspace or can only >be >> controlled from kernel space into the DT would be a layering >violation. It >> is analogous to why we don't have spidev DT bindings. This is an >issue that >> needs to be solved at a higher level. In my opinion this level is a >> cooperation between kernel- and userspace. Kernelspace offering an >interface >> to export a device for userspace access and userspace making use of >that >> interface to request access to a device. In a similar way to how vfio >is >> structured. > >I'm not advocating using DT for policy, only for hardware description. > >We have means (bindings) to describe GPIOs connected to LEDs and >switches >(incl. their labels), while you can control LEDs through plain GPIO >sysfs >export or chardev, too. It's just more error prone to use the latter. > >We do not have bindings to describe GPIOs connected to e.g. relays. We should. > >Switching external devices (the internals of those devices not >described >itself in DT, like in an industrial context), sounds more like >something to >be handled by IIO, doesn't it? Certainly, if there is known hardware to describe, we should endeavour to describe it. Userspace interfaces are needed wherever we hit the boundary of what we can describe, whether because we are measuring things not in our control (e.g. what key is pressed on a keyboard) or because the next bit of hardware is interchangeable (e.g. your relay example, or this power switch). The challenge is to structure the device model for the interchangeable edge case to be the same, more or less, as it would be if we knew what was hanging off the switch. Hence, we either cut out early (gpio) or we attempt to put an appropriate consumer in place for the gpio (or possibly the power switch if we describe that). No problem at all in doing that last chunk with IIO or GPIO userspace as appropriate... The challenge is that we are representing the fact the hardware is unknown in device tree. Perhaps we need a way to make that explicit? Is there one already? Things like extcon do similar things I guess. Same is true for regulators, when they are at the edge of the device... On the binary channel types in IIO we have discussed this a fair bit in the past. There Is a non trivial amount of work needed to do triggered input (demuxing to multiple consumers In particular). Sysfs stuff would be simple but then it would really be gpio interface wrapped up a bit. What IIO would bring to the mix ultimately is synchronized triggering of input and output. (Speaking of which, Lars any progress on output buffers? Perhaps if we post that someone else might pick it up and run with it?) One could argue the relay case is more of a mux than anything else so perhaps the ongoing generic mux subsystem discussion would be a good place to talk about that? Interesting discussion, sorry it took me until my Christmas train journey to join in). Linus, if you get a chance, you have probably thought more about gpio IIO interactions than I have! Jonathan > >Gr{oetje,eeting}s, > > Geert > >-- >Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- >geert@linux-m68k.org > >In personal conversations with technical people, I call myself a >hacker. But >when I'm talking to journalists I just say "programmer" or something >like that. > -- Linus Torvalds >-- >To unsubscribe from this list: send the line "unsubscribe linux-iio" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 13, 2016 at 3:28 PM, Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: > + Linus > > While the new GPIO interface would be very convenient - in our case we > could simply name the lines appropriately in the device tree - I'm not > sure this would be the correct approach. > > From this year's ELCE in Berlin I remember Linus suggested during his > talk that it's always better to write a kernel driver. Also: this way > the relevant GPIO lines would not be reserved for exclusive use by > power switches. > > Linus - do you have any thoughts/suggestions on that subject? If the probe you are power cycling has its own DT node and is described as a device per se in the system, then it should have a device driver grabbing and toggling its own GPIO line. If the probe is only really known in userspace, and driven from userspace, it's GPIO reset line should also be driven from userspace, using the chardev ABI as you describe. Whether something should have a userspace or kernelspace driver is a gray area, admittedly. There are cases for both. The general consideration would be reuse and deployment. If you expect all users of this probe to always use libiio and some other userspace, I guess userspace-only makes sense? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 12/23/2016 11:00 AM, Geert Uytterhoeven wrote: > Well, it is a policy question. Who gets access to what. Right now it is all > or nothing, a privileged application gets access to all devices/GPIOs, a > unprivileged application gets access to nothing. Same for GPIOs as well as > IIO devices. > > iiod at the moment does not have any access control at all, which in itself > is a problem. We need to add support for that at some point. I don't see an > issue with implementing a finer grained access scheme when we do so. E.g. > unprivileged applications only get access to certain pins. I don't know why this is percieved as such a big practical problem. It seems to me as more of a theoretical exploit path than a practical one. (Famous last words...) We have per-device and not per-line GPIO access restrictions. /dev/gpiochip0 /dev/gpiochip1 etc can all have per-device access restrictions. This is no different from /dev/sda for example. You do not have per-sector control of the block device, because it doesn't make sense. Either you access all of the device, or nothing. The same goes for IIO devices. This pattern is very clear. You get access to a whole device or none of it. As with disks and IIO devices, if you want more granular access restrictions, that is policy, and should reside in userspace. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 23, 2016 at 01:56:11PM +0100, Geert Uytterhoeven wrote: > On Fri, Dec 23, 2016 at 12:35 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > > cooperation between kernel- and userspace. Kernelspace offering an interface > > to export a device for userspace access and userspace making use of that > > interface to request access to a device. In a similar way to how vfio is > > structured. ... > We do not have bindings to describe GPIOs connected to e.g. relays. Well, it depends what the relays are doing in the system of course... > Switching external devices (the internals of those devices not described > itself in DT, like in an industrial context), sounds more like something to > be handled by IIO, doesn't it? The BayLibre ACME systems have a case like this with their power metering stuff (I've got a similar but more overenginered board I'm in theory working on with actual relays). The system itself is controlling a power line, it knows nothing about what's connected. It seems like this is coming up often enough that someone should probably just write an external system control binding, also tying in things like references to the console and so on.
diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/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 device +driver representing a physical regulator within the iio framework. + +Required properties: + +- compatible: must be "iio-regulator" +- vcc-supply: phandle of the regulator this device represents + +Example +------- + +iio_regulator { + compatible = "iio-regulator"; + vcc-supply = <&vcc0>; +}; diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig index 6743b18..2e896e0 100644 --- a/drivers/iio/Kconfig +++ b/drivers/iio/Kconfig @@ -80,6 +80,7 @@ source "drivers/iio/gyro/Kconfig" source "drivers/iio/health/Kconfig" source "drivers/iio/humidity/Kconfig" source "drivers/iio/imu/Kconfig" +source "drivers/iio/misc/Kconfig" source "drivers/iio/light/Kconfig" source "drivers/iio/magnetometer/Kconfig" source "drivers/iio/orientation/Kconfig" diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile index 87e4c43..4008d5a 100644 --- a/drivers/iio/Makefile +++ b/drivers/iio/Makefile @@ -25,6 +25,7 @@ obj-y += frequency/ obj-y += health/ obj-y += humidity/ obj-y += imu/ +obj-y += misc/ obj-y += light/ obj-y += magnetometer/ obj-y += orientation/ diff --git a/drivers/iio/misc/Kconfig b/drivers/iio/misc/Kconfig new file mode 100644 index 0000000..b43a1ed --- /dev/null +++ b/drivers/iio/misc/Kconfig @@ -0,0 +1,17 @@ +# +# Miscellaneous iio drivers +# +# When adding new entries keep the list in alphabetical order + +menu "Miscellaneous iio drivers" + +config IIO_REGULATOR + tristate "IIO regulator driver" + depends on REGULATOR + help + Say yes here to build support for regulators powering iio devices. + + To compile this driver as a module, choose M here: the module will + be called iio-regulator. + +endmenu diff --git a/drivers/iio/misc/Makefile b/drivers/iio/misc/Makefile new file mode 100644 index 0000000..da8f56a --- /dev/null +++ b/drivers/iio/misc/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for IIO misc drivers +# + +# When adding new entries keep the list in alphabetical order +obj-$(CONFIG_IIO_REGULATOR) += iio-regulator.o diff --git a/drivers/iio/misc/iio-regulator.c b/drivers/iio/misc/iio-regulator.c new file mode 100644 index 0000000..0d61553 --- /dev/null +++ b/drivers/iio/misc/iio-regulator.c @@ -0,0 +1,121 @@ +/* + * Generic regulator driver for industrial IO. + * + * Copyright (C) 2016 BayLibre SAS + * + * Author: + * Bartosz Golaszewski <bgolaszewski@baylibre.com.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/regulator/consumer.h> +#include <linux/iio/iio.h> +#include <linux/iio/sysfs.h> + +struct iio_regulator_context { + struct regulator *regulator; +}; + +static ssize_t iio_regulator_enable_show(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev)); + + return sprintf(buf, "%d\n", regulator_is_enabled(ctx->regulator)); +} + +static ssize_t iio_regulator_enable_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t len) +{ + struct iio_regulator_context *ctx = iio_priv(dev_to_iio_dev(dev)); + int ret, enabled; + bool val; + + ret = strtobool(buf, &val); + if (ret) + return ret; + + enabled = regulator_is_enabled(ctx->regulator); + if ((val && enabled) || (!val && !enabled)) + return -EPERM; + + ret = val ? regulator_enable(ctx->regulator) : + regulator_disable(ctx->regulator); + if (ret) + return ret; + + return len; +} + +static IIO_DEVICE_ATTR(in_enable, 0644, + iio_regulator_enable_show, + iio_regulator_enable_store, 0); + +static struct attribute *iio_regulator_attributes[] = { + &iio_dev_attr_in_enable.dev_attr.attr, + NULL, +}; + +static const struct attribute_group iio_regulator_attribute_group = { + .attrs = iio_regulator_attributes, +}; + +static const struct iio_info iio_regulator_info = { + .driver_module = THIS_MODULE, + .attrs = &iio_regulator_attribute_group, +}; + +static int iio_regulator_probe(struct platform_device *pdev) +{ + struct iio_regulator_context *ctx; + struct iio_dev *iio_dev; + struct device *dev; + + dev = &pdev->dev; + + iio_dev = devm_iio_device_alloc(dev, sizeof(*ctx)); + if (!iio_dev) + return -ENOMEM; + + ctx = iio_priv(iio_dev); + + ctx->regulator = devm_regulator_get(dev, "vcc"); + if (IS_ERR(ctx->regulator)) { + dev_err(dev, "unable to get vcc regulator: %ld\n", + PTR_ERR(ctx->regulator)); + return PTR_ERR(ctx->regulator); + } + + iio_dev->dev.parent = dev; + iio_dev->dev.of_node = dev->of_node; + iio_dev->name = dev->driver->name; + iio_dev->info = &iio_regulator_info; + + return devm_iio_device_register(dev, iio_dev); +} + +static const struct of_device_id iio_regulator_of_match[] = { + { .compatible = "iio-regulator", }, + { }, +}; + +static struct platform_driver iio_regulator_platform_driver = { + .probe = iio_regulator_probe, + .driver = { + .name = "iio-regulator", + .of_match_table = iio_regulator_of_match, + }, +}; +module_platform_driver(iio_regulator_platform_driver); + +MODULE_AUTHOR("Bartosz Golaszewski <bgolaszewski@baylibre.com>"); +MODULE_DESCRIPTION("Regulator driver for iio"); +MODULE_LICENSE("GPL v2");
Some iio devices are powered externally by a regulator which, for example, can be used to power-cycle an adc. This patch proposes to add a simple driver representing a regulator to the iio framework which exports attributes allowing to manipulate the underlying hardware. The reason for connecting the regulator and the iio frameworks is that once libiio learns to toggle iio attributes we'll be able to power-cycle devices remotely. Initially the driver only supports enable/disable operations, but it should be straightforward to extend it with other regulator operations in the future. Tested with a baylibre-acme board for beaglebone black. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> --- .../devicetree/bindings/iio/misc/iio-regulator.txt | 18 +++ drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + drivers/iio/misc/Kconfig | 17 +++ drivers/iio/misc/Makefile | 6 + drivers/iio/misc/iio-regulator.c | 121 +++++++++++++++++++++ 6 files changed, 164 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/misc/iio-regulator.txt create mode 100644 drivers/iio/misc/Kconfig create mode 100644 drivers/iio/misc/Makefile create mode 100644 drivers/iio/misc/iio-regulator.c -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html