* [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs @ 2019-09-09 10:59 Uwe Kleine-König 2019-09-12 9:05 ` Linus Walleij 0 siblings, 1 reply; 3+ messages in thread From: Uwe Kleine-König @ 2019-09-09 10:59 UTC (permalink / raw) To: Linus Walleij, Bartosz Golaszewski; +Cc: linux-gpio, kernel, linux-arm-kernel Sometimes it is handy to be able to easily define a "safe" state for a GPIO. This might for example be used to ensure that an ethernet phy is properly reset during startup or just that all pins have a defined state to minimize leakage current. As such a pin must be requestable (and changable) by a device driver, a gpio-hog cannot be used. So define a GPIO initializer with a syntax identical to a GPIO hog just using "gpio-init" as identifier instead of "gpio-hog". The usage I have in mind (and also implemented in a custom patch stack on top of barebox already) is targeting the bootloader and not necessarily Linux as such an boot-up initialisation should be done as early as possible. Not-yet-signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- Hello, maybe it also makes sense to use "gpio-safe"? Maybe it (then) makes sense to reset the gpio in the indicated state after it is released? Also it might be beneficial to make the wording more explicit in the description and for example tell that only one of gpio-hog and gpio-init must be provided. Best regards Uwe Documentation/devicetree/bindings/gpio/gpio.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index a8895d339bfe..5b7883f5520f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -182,13 +182,16 @@ gpio-controller@00000000 { "poweroff", "reset"; } -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism -providing automatic GPIO request and configuration as part of the -gpio-controller's driver probe function. +The GPIO chip may contain GPIO hog and init definitions. GPIO hogging is a +mechanism providing automatic GPIO request and configuration as part of the +gpio-controller's driver probe function. An GPIO initializer is similar but +doesn't prevent later requesting and reconfiguration. Each GPIO hog definition is represented as a child node of the GPIO controller. Required properties: - gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpio-init: A property specifying that this child node represents a GPIO + initializer. - gpios: Store the GPIO information (id, flags, ...) for each GPIO to affect. Shall contain an integer multiple of the number of cells specified in its parent node (GPIO controller node). -- 2.23.0 ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs 2019-09-09 10:59 [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs Uwe Kleine-König @ 2019-09-12 9:05 ` Linus Walleij 2019-09-12 10:06 ` Uwe Kleine-König 0 siblings, 1 reply; 3+ messages in thread From: Linus Walleij @ 2019-09-12 9:05 UTC (permalink / raw) To: Uwe Kleine-König Cc: Bartosz Golaszewski, open list:GPIO SUBSYSTEM, Sascha Hauer, Linux ARM On Mon, Sep 9, 2019 at 11:59 AM Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote: > Sometimes it is handy to be able to easily define a "safe" state for a > GPIO. This might for example be used to ensure that an ethernet phy is > properly reset during startup or just that all pins have a defined state > to minimize leakage current. As such a pin must be requestable (and > changable) by a device driver, a gpio-hog cannot be used. > > So define a GPIO initializer with a syntax identical to a GPIO hog just > using "gpio-init" as identifier instead of "gpio-hog". > > The usage I have in mind (and also implemented in a custom patch stack > on top of barebox already) is targeting the bootloader and not > necessarily Linux as such an boot-up initialisation should be done as > early as possible. > > Not-yet-signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > Hello, > > maybe it also makes sense to use "gpio-safe"? Maybe it (then) makes > sense to reset the gpio in the indicated state after it is released? > > Also it might be beneficial to make the wording more explicit in the > description and for example tell that only one of gpio-hog and gpio-init > must be provided. It's no secret that I am in favor of this approach, as I like consistency with the hogs. The DT people have been against, as they prefer something like an initial array of values akin to gpio-names IIRC. But this is a good time for them to speak up. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs 2019-09-12 9:05 ` Linus Walleij @ 2019-09-12 10:06 ` Uwe Kleine-König 0 siblings, 0 replies; 3+ messages in thread From: Uwe Kleine-König @ 2019-09-12 10:06 UTC (permalink / raw) To: Linus Walleij Cc: Bartosz Golaszewski, Linux ARM, Sascha Hauer, open list:GPIO SUBSYSTEM, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree On Thu, Sep 12, 2019 at 10:05:23AM +0100, Linus Walleij wrote: > On Mon, Sep 9, 2019 at 11:59 AM Uwe Kleine-König > <u.kleine-koenig@pengutronix.de> wrote: > > > Sometimes it is handy to be able to easily define a "safe" state for a > > GPIO. This might for example be used to ensure that an ethernet phy is > > properly reset during startup or just that all pins have a defined state > > to minimize leakage current. As such a pin must be requestable (and > > changable) by a device driver, a gpio-hog cannot be used. > > > > So define a GPIO initializer with a syntax identical to a GPIO hog just > > using "gpio-init" as identifier instead of "gpio-hog". > > > > The usage I have in mind (and also implemented in a custom patch stack > > on top of barebox already) is targeting the bootloader and not > > necessarily Linux as such an boot-up initialisation should be done as > > early as possible. > > > > Not-yet-signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > --- > > Hello, > > > > maybe it also makes sense to use "gpio-safe"? Maybe it (then) makes > > sense to reset the gpio in the indicated state after it is released? > > > > Also it might be beneficial to make the wording more explicit in the > > description and for example tell that only one of gpio-hog and gpio-init > > must be provided. > > It's no secret that I am in favor of this approach, as I like consistency > with the hogs. > > The DT people have been against, as they prefer something like an > initial array of values akin to gpio-names IIRC. But this is a good > time for them to speak up. To be fair, I added them to Cc:. For the new readers: The diff I suggested looks as follows (probably whitespace broken as I cut-n-pasted): > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt > index a8895d339bfe..5b7883f5520f 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt > @@ -182,13 +182,16 @@ gpio-controller@00000000 { > "poweroff", "reset"; > } > > -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism > -providing automatic GPIO request and configuration as part of the > -gpio-controller's driver probe function. > +The GPIO chip may contain GPIO hog and init definitions. GPIO hogging is a > +mechanism providing automatic GPIO request and configuration as part of the > +gpio-controller's driver probe function. An GPIO initializer is similar but > +doesn't prevent later requesting and reconfiguration. > > Each GPIO hog definition is represented as a child node of the GPIO controller. > Required properties: > - gpio-hog: A property specifying that this child node represents a GPIO hog. > +- gpio-init: A property specifying that this child node represents a GPIO > + initializer. > - gpios: Store the GPIO information (id, flags, ...) for each GPIO to > affect. Shall contain an integer multiple of the number of cells > specified in its parent node (GPIO controller node). How would this alternate approach look like? Something like: gpio-controler@123450 { compatible = ".."; gpio-controller; #gpio-cells = <2>; init = "", "output-high", "", "input", "", "", "output-low"; }; ? Compared to the solution I suggested (and hogs) this differs as you cannot pass flags like GPIO_ACTIVE_LOW. (Sidenode: As mygpio { gpio-hog; gpios = <5 GPIO_ACTIVE_LOW>; output-low; }; makes AFAIK the output high it would be less surprising if the binding supported "output-active" and "output-inactive".) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-09-12 10:07 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-09 10:59 [PATCH RFC] gpio: define gpio-init nodes to initialize pins similar to hogs Uwe Kleine-König 2019-09-12 9:05 ` Linus Walleij 2019-09-12 10:06 ` Uwe Kleine-König
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).