Hi Lars, On Mon, Dec 12, 2016 at 6:15 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html