diff options
Diffstat (limited to 'drivers/gpio/TODO')
| -rw-r--r-- | drivers/gpio/TODO | 144 |
1 files changed, 83 insertions, 61 deletions
diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO index b8b1473a5b1e..5acaeab029ec 100644 --- a/drivers/gpio/TODO +++ b/drivers/gpio/TODO @@ -1,6 +1,7 @@ This is a place for planning the ongoing long-term work in the GPIO subsystem. +=============================================================================== GPIO descriptors @@ -43,11 +44,19 @@ 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 <linux/gpio.h> altogether. +------------------------------------------------------------------------------- Get rid of <linux/of_gpio.h> @@ -59,15 +68,10 @@ the device tree back-end. It is legacy and should not be used in new code. Work items: -- Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO - GPIO for all current users (see below). Delete struct of_mm_gpio_chip, - to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_add() - of_mm_gpiochip_remove() from the kernel. - - Change all consumer drivers that #include <linux/of_gpio.h> to #include <linux/gpio/consumer.h> and stop doing custom parsing of the - GPIO lines from the device tree. This can be tricky and often ivolves - changing boardfiles, etc. + GPIO lines from the device tree. This can be tricky and often involves + changing board files, etc. - Pull semantics for legacy device tree (OF) GPIO lookups into gpiolib-of.c: in some cases subsystems are doing custom flags and @@ -80,15 +84,7 @@ Work items: - Delete <linux/of_gpio.h> when all the above is complete and everything uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead. - -Get rid of <linux/gpio.h> - -This legacy header is a one stop shop for anything GPIO is closely tied -to the global GPIO numberspace. The endgame of the above refactorings will -be the removal of <linux/gpio.h> and from that point only the specialized -headers under <linux/gpio/*.h> will be used. This requires all the above to -be completed and is expected to take a long time. - +------------------------------------------------------------------------------- Collect drivers @@ -103,6 +99,7 @@ At the same time it makes sense to get rid of code duplication in existing or new coming drivers. For example, gpio-ml-ioh should be incorporated into gpio-pch. +------------------------------------------------------------------------------- Generic MMIO GPIO @@ -123,6 +120,15 @@ 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 +------------------------------------------------------------------------------- + +Generic regmap GPIO + +In the very similar way to Generic MMIO GPIO convert the users which can +take advantage of using regmap over direct IO accessors. Note, even in +MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c. + +------------------------------------------------------------------------------- GPIOLIB irqchip @@ -132,49 +138,65 @@ try to cover any generic kind of irqchip cascaded from a GPIO. - Look over and identify any remaining easily converted drivers and dry-code conversions to gpiolib irqchip for maintainers to test +------------------------------------------------------------------------------- + +Moving over to immutable irq_chip structures + +Most of the gpio chips implementing interrupt support rely on gpiolib +intercepting some of the irq_chip callbacks, preventing the structures +from being made read-only and forcing duplication of structures that +should otherwise be unique. + +The solution is to call into the gpiolib code when needed (resource +management, enable/disable or unmask/mask callbacks), and to let the +core code know about that by exposing a flag (IRQCHIP_IMMUTABLE) in +the irq_chip structure. The irq_chip structure can then be made unique +and const. + +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! + +------------------------------------------------------------------------------- + +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. + +------------------------------------------------------------------------------- + +Remove devm_gpiod_unhinge() -Increase integration with pin control - -There are already ways to use pin control as back-end for GPIO and -it may make sense to bring these subsystems closer. One reason for -creating pin control as its own subsystem was that we could avoid any -use of the global GPIO numbers. Once the above is complete, it may -make sense to simply join the subsystems into one and make pin -multiplexing, pin configuration, GPIO, etc selectable options in one -and the same pin control and GPIO subsystem. - - -Debugfs in place of sysfs - -The old sysfs code that enables simple uses of GPIOs from the -command line is still popular despite the existance of the proper -character device. The reason is that it is simple to use on -root filesystems where you only have a minimal set of tools such -as "cat", "echo" etc. - -The old sysfs still need to be strongly deprecated and removed -as it relies on the global GPIO numberspace that assume a strict -order of global GPIO numbers that do not change between boots -and is independent of probe order. - -To solve this and provide an ABI that people can use for hacks -and development, implement a debugfs interface to manipulate -GPIO lines that can do everything that sysfs can do today: one -directory per gpiochip and one file entry per line: - -/sys/kernel/debug/gpiochip/gpiochip0 -/sys/kernel/debug/gpiochip/gpiochip0/gpio0 -/sys/kernel/debug/gpiochip/gpiochip0/gpio1 -/sys/kernel/debug/gpiochip/gpiochip0/gpio2 -/sys/kernel/debug/gpiochip/gpiochip0/gpio3 -... -/sys/kernel/debug/gpiochip/gpiochip1 -/sys/kernel/debug/gpiochip/gpiochip1/gpio0 -/sys/kernel/debug/gpiochip/gpiochip1/gpio1 -... - -The exact files and design of the debugfs interface can be -discussed but the idea is to provide a low-level access point -for debugging and hacking and to expose all lines without the -need of any exporting. Also provide ample ammunition to shoot -oneself in the foot, because this is debugfs after all. +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. |