On Wed, Sep 14, 2022 at 6:21 PM Kent Gibson <warthog618@xxxxxxxxx> wrote: > > 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. > idle-state it is then. > 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? > No, this should only be defined on the device tree or in ACPI. As the HW policy of a device. I don't think we should allow user-space to override this behavior. > 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. > This "idle-state" property wouldn't be mandatory and normally would only be defined for a limited set of lines. I'd say we just override whatever the driver does in free() (most drivers don't implement it BTW) and do what the property says we should. Bart