| Message ID | 20220914151145.73253-1-brgl@bgdev.pl |
|---|---|
| State | New |
| Headers | show |
| Series | gpiolib: TODO: add an item about GPIO safe-state | expand |
On Thu, Sep 15, 2022 at 10:59 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Wed, Sep 14, 2022 at 5:11 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > This adds a new TODO item for gpiolib and can also be used to start > > a discussion about the need for it and implementation details. > > > > Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> > > Acked-by: Linus Walleij <linus.walleij@linaro.org> > > Several approaches have been tried in the past. Consider adding > these lore links: > > "[PATCH 3/4] gpio: dt-bindings: Declare gpio-hog optional for GPIO > subnodes" (2016) > https://lore.kernel.org/linux-devicetree/1456214089-13954-3-git-send-email-mpa@pengutronix.de/ > "[PATCH] gpio: 74x164: add lines-initial-states property" (2018) > https://lore.kernel.org/lkml/20180815201855.29738-1-mail@david-bauer.net/" > "[RFC] Initial state for GPIOs" (2019) > https://lore.kernel.org/linux-gpio/bee53b48c96603ae8970d42bc4bff386b876bc51.camel@collabora.com/ > > Just so we don't have to constantly look them up for referral. > Of course we were not the first ones to think about it... I'll read through it later. Was there any particular reason why this never made its way into the kernel? Bart
On Fri, Sep 16, 2022 at 8:12 AM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Fri, Sep 16, 2022 at 9:11 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > Of course we were not the first ones to think about it... > > :D > > > I'll read through it later. Was there any particular reason why this > > never made its way into the kernel? > > Inability to drive through a DT binding that was acceptable for the > DT binding maintainers. AFAICT, this came up briefly in 2015, then 2017, then 2019. (You're a year late this time.) A nice regular pattern to not get something upstream... > A good idea to get it passed I think would be to ask Rob (with some > examples) how he thinks it should look and finalize the bindings > before coding. My issue was more that by the time the kernel or even bootloader runs, quite a bit of time has passed given all the firmware that runs nowadays. Doesn't a safe state need to be set as early as possible? Like probably before anything using DT? A node per GPIO could end up being a lot of nodes and I can certainly see folks just initializing every GPIO. That would be a lot of bloat. As I see it we need 4 bits per line: direction, state(high/low), pull up/down/none. Finally, don't non-GPIO pins need the same thing? You don't want a default output driving what needs to be an input. Of course, a good h/w designer wouldn't design such a thing. Rob
diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO index f87ff3fa8a53..6ab39c5cec9d 100644 --- a/drivers/gpio/TODO +++ b/drivers/gpio/TODO @@ -197,3 +197,25 @@ A small number of drivers have been converted (pl061, tegra186, msm, amd, apple), and can be used as examples of how to proceed with this conversion. Note that drivers using the generic irqchip framework cannot be converted yet, but watch this space! + +Safe-state of GPIOs + +During 2022 Linux Plumbers Conference's GPIO & pinctrl BOF it's been discussed +that we don't have any middle ground between hogging GPIO lines and letting the +user (either in-kernel or user-space) control them. Either the lines are forever +reserved as hogs or their state is undefined unless requested. + +Currently the behavior of GPIOs that were not requested or were released is +largely driver dependent (the provider driver decides whether the line's state +is reverted to some predefined value or left as-is). This can be problematic +as the output state of a line can damage physical hardware. + +This item is about proposing a solution, most likely in the form of a new device +property called "safe-state" that would define the safe states of specific lines +(e.g. output-high) but not block the line from being requested by users who +could then modify that default state. Once released the GPIO core would then +put the line back into the "safe-state". + +While this could potentially be seen as defining policy in the device-tree, it's +not anymore a policy than properties such as "regulator-always-on" or gpio-hogs +themselves are.
This adds a new TODO item for gpiolib and can also be used to start a discussion about the need for it and implementation details. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> --- drivers/gpio/TODO | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)