Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Bartosz Golaszewski <brgl@bgdev.pl>
To:     Kent Gibson <warthog618@gmail.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Drew Fustini <dfustini@baylibre.com>,
        Marek Vasut <marek.vasut@gmail.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        Bartosz Golaszewski <brgl@bgdev.pl>
Subject: [PATCH] gpiolib: TODO: add an item about GPIO safe-state
Date:   Wed, 14 Sep 2022 17:11:45 +0200
Message-Id: <20220914151145.73253-1-brgl@bgdev.pl>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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(+)

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.
-- 
2.34.1