Re: [PATCH] gpiolib: TODO: add an item about GPIO safe-state

[Kent Gibson]

On Wed, Sep 14, 2022 at 05:11:45PM +0200, Bartosz Golaszewski 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@xxxxxxxx>
> ---
>  drivers/gpio/TODO | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
> 
> 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".
> +

Geert suggests idle-state, rather than safe-state, but you call it
the "default state" here as well - pick one.

So this idle-state would be another attribute on a line that the user
could configure via the GPIO uAPI, and so replicate the "set and forget"
sysfs behavior that we are currently missing, and which seems to be the
biggest sticking point for a transition away from sysfs?

For backward compatibility the default idle-state, i.e. the value the
idle-state would take if not explicitly set, would map to existing
behaviour, so let the driver decide?

What happens when gpiolib frees the line?  Isn't the driver still able
to do what it likes to the line at that point, no matter what GPIO core
has set it to previously? e.g. gpio_sim_free() restores the line to its
own internal pull value.
 
Cheers,
Kent.