diff options
Diffstat (limited to 'drivers/gpio/TODO')
| -rw-r--r-- | drivers/gpio/TODO | 58 |
1 files changed, 50 insertions, 8 deletions
diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO index b5f0a7a2e1bf..7a09a4f58551 100644 --- a/drivers/gpio/TODO +++ b/drivers/gpio/TODO @@ -44,6 +44,13 @@ Work items: to a machine description such as device tree, ACPI or fwnode that implicitly does not use global GPIO numbers. +- Fix drivers to not read back struct gpio_chip::base. Some drivers do + that and would be broken by attempts to poison it or make it dynamic. + Example in AT91 pinctrl driver: + https://lore.kernel.org/all/1d00c056-3d61-4c22-bedd-3bae0bf1ddc4@pengutronix.de/ + This particular driver is also DT-only, so with the above fixed, the + base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled. + - When this work is complete (will require some of the items in the following ongoing work as well) we can delete the old global numberspace accessors from <linux/gpio.h> and eventually delete @@ -124,6 +131,11 @@ Work items: helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use this with dry-coding and sending to maintainers to test +- Move the MMIO GPIO specific fields out of struct gpio_chip into a + dedicated structure. Currently every GPIO chip has them if gpio-mmio is + enabled in Kconfig even if it itself doesn't register with the helper + library. + ------------------------------------------------------------------------------- Generic regmap GPIO @@ -176,13 +188,43 @@ remove the old ones and finally rename the new ones back to the old names. ------------------------------------------------------------------------------- -Extend the sysfs ABI to allow exporting lines by their HW offsets +Remove legacy sysfs features + +We have two parallel per-chip class devices and per-exported-line attribute +groups in sysfs. One is using the obsolete global GPIO numberspace and the +second relies on hardware offsets of pins within the chip. Remove the former +once user-space has switched to using the latter. + +------------------------------------------------------------------------------- + +Remove GPIOD_FLAGS_BIT_NONEXCLUSIVE + +GPIOs in the linux kernel are meant to be an exclusive resource. This means +that the GPIO descriptors (the software representation of the hardware concept) +are not reference counted and - in general - only one user at a time can +request a GPIO line and control its settings. The consumer API is designed +around full control of the line's state as evidenced by the fact that, for +instance, gpiod_set_value() does indeed drive the line as requested, instead +of bumping an enable counter of some sort. + +A problematic use-case for GPIOs is when two consumers want to use the same +descriptor independently. An example of such a user is the regulator subsystem +which may instantiate several struct regulator_dev instances containing +a struct device but using the same enable GPIO line. + +A workaround was introduced in the form of the GPIOD_FLAGS_BIT_NONEXCLUSIVE +flag but its implementation is problematic: it does not provide any +synchronization of usage nor did it introduce any enable count meaning the +non-exclusive users of the same descriptor will in fact "fight" for the +control over it. This flag should be removed and replaced with a better +solution, possibly based on the new power sequencing subsystem. + +------------------------------------------------------------------------------- -The need to support the sysfs GPIO class is one of the main obstacles to -removing the global GPIO numberspace from the kernel. In order to wean users -off using global numbers from user-space, extend the existing interface with -new per-gpiochip export/unexport attributes that allow to refer to GPIOs using -their hardware offsets within the chip. +Remove devm_gpiod_unhinge() -Encourage users to switch to using them and eventually remove the existing -global export/unexport attribues. +devm_gpiod_unhinge() is provided as a way to transfer the ownership of managed +enable GPIOs to the regulator core. Rather than doing that however, we should +make it possible for the regulator subsystem to deal with GPIO resources the +lifetime of which it doesn't control as logically, a GPIO obtained by a caller +should also be freed by it. |