Hi Benoit, > On Oct 21, 2014, at 23:09 , Benoit Parrot <bparrot@xxxxxx> wrote: > > Based on Boris Brezillion work this is a reworked patch > of his initial GPIO hogging mechanism. > This patch provides a way to initally configure specific GPIO > when the gpio controller is probe. > > The actual DT scanning to collect the GPIO specific data is performed > as part of the gpiochip_add(). > > The purpose of this is to allows specific GPIOs to be configured > without any driver specific code. > This particularly usueful because board design are getting > increassingly complex and given SoC pins can now have upward > of 10 mux values a lot of connections are now dependent on > external IO muxes to switch various modes and combination. > > Specific drivers should not necessarily need to be aware of > what accounts to a specific board implementation. This board level > "description" should be best kept as part of the dts file. > This look like it’s going to the right direction. I have a few general comments at first. 1) It relies on dubious DT binding of having sub-nodes of the gpio device implicitly defining hogs. 2) There is no way for having hogs inserted dynamically as far as I can tell, and no way to remove a hog either. 3) I’m not very fond of having this being part of the gpio controller. This configuration conceptually has little to do with the gpio controller per se, it is more of a board specific thing. Why not come up with a gpio-hog driver that references GPIOs? That way with a single gpio-hog driver instance you could setup all the GPIO-hogging configuration for all GPIOs on the board, even one that lie on different GPIO controllers. > Signed-off-by: Benoit Parrot <bparrot@xxxxxx> > --- > Documentation/devicetree/bindings/gpio/gpio.txt | 33 +++++++++ > drivers/gpio/gpiolib-of.c | 99 +++++++++++++++++++++++++ > drivers/gpio/gpiolib.c | 81 ++++++++++++++++++++ > include/linux/of_gpio.h | 11 +++ > 4 files changed, 224 insertions(+) > Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html