TODO - OpenGrok cross reference for /linux-6.15/drivers/gpio/TODO

1 This is a place for planning the ongoing long-term work in the GPIO
6 GPIO descriptors
8 Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey
9 to move away from the global GPIO numberspace and toward a descriptor-based
10 approach. This means that GPIO consumers, drivers and machine descriptions
11 ideally have no use or idea of the global GPIO numberspace that has/was
12 used in the inception of the GPIO subsystem.
17 The underlying motivation for this is that the GPIO numberspace has become
19 establish the numberspace at compile-time, making it hard to add any numbers
20 in the middle (such as if you missed a pin on a chip) without the numberspace
23 Machine descriptions such as device tree or ACPI does not have a concept of the
24 Linux GPIO number as those descriptions are external to the Linux kernel
25 and treat GPIO lines as abstract entities.
27 The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
28 base as -1 in struct gpio_chip) has also became unpredictable due to factors
29 such as probe ordering and the introduction of -EPROBE_DEFER making probe
30 ordering of independent GPIO chips essentially unpredictable, as their base
31 number will be assigned on a first come first serve basis.
33 The best way to get out of the problem is to make the global GPIO numbers
34 unimportant by simply not using them. GPIO descriptors deal with this.
38 - Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
40 - Convert all consumer drivers to only #include <linux/gpio/consumer.h>
42 - Convert all machine descriptors in "boardfiles" to only
43   #include <linux/gpio/machine.h>, the other option being to convert it
44   to a machine description such as device tree, ACPI or fwnode that
45   implicitly does not use global GPIO numbers.
47 - When this work is complete (will require some of the items in the
49   numberspace accessors from <linux/gpio.h> and eventually delete
50   <linux/gpio.h> altogether.
52 -------------------------------------------------------------------------------
57 driver infrastructure for doing simpler MMIO GPIO devices and there was
60 the device tree back-end. It is legacy and should not be used in new code.
64 - Change all consumer drivers that #include <linux/of_gpio.h> to
65   #include <linux/gpio/consumer.h> and stop doing custom parsing of the
66   GPIO lines from the device tree. This can be tricky and often involves
69 - Pull semantics for legacy device tree (OF) GPIO lookups into
70   gpiolib-of.c: in some cases subsystems are doing custom flags and
77 - Delete <linux/of_gpio.h> when all the above is complete and everything
78   uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
80 -------------------------------------------------------------------------------
82 Get rid of <linux/gpio/legacy-of-mm-gpiochip.h>
86 - Get rid of struct of_mm_gpio_chip altogether: use the generic  MMIO
87   GPIO for all current users (see below). Delete struct of_mm_gpio_chip,
91 -------------------------------------------------------------------------------
95 Collect GPIO drivers from arch/* and other places that should be placed
96 in drivers/gpio/gpio-*. Augment platforms to create platform devices or
97 similar and probe a proper driver in the gpiolib subsystem.
99 In some cases it makes sense to create a GPIO chip from the local driver
100 for a few GPIOs. Those should stay where they are.
103 new coming drivers. For example, gpio-ml-ioh should be incorporated into
104 gpio-pch.
106 -------------------------------------------------------------------------------
108 Generic MMIO GPIO
110 The GPIO drivers can utilize the generic MMIO helper library in many
112 drivers. (drivers/gpio/gpio-mmio.c)
116 - Look over and identify any remaining easily converted drivers and
117   dry-code conversions to MMIO GPIO for maintainers to test
119 - Expand the MMIO GPIO or write a new library for regmap-based I/O
120   helpers for GPIO drivers on regmap that simply use offsets
121   0..n in some register to drive GPIO lines
123 - Expand the MMIO GPIO or write a new library for port-mapped I/O
124   helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
125   this with dry-coding and sending to maintainers to test
127 -------------------------------------------------------------------------------
129 Generic regmap GPIO
131 In the very similar way to Generic MMIO GPIO convert the users which can
133 MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c.
135 -------------------------------------------------------------------------------
139 The GPIOLIB irqchip is a helper irqchip for "simple cases" that should
140 try to cover any generic kind of irqchip cascaded from a GPIO.
142 - Look over and identify any remaining easily converted drivers and
143   dry-code conversions to gpiolib irqchip for maintainers to test
145 -------------------------------------------------------------------------------
149 Most of the gpio chips implementing interrupt support rely on gpiolib
151 from being made read-only and forcing duplication of structures that
156 core code know about that by exposing a flag (IRQCHIP_IMMUTABLE) in
160 A small number of drivers have been converted (pl061, tegra186, msm,
165 -------------------------------------------------------------------------------
167 Convert all GPIO chips to using the new, value returning line setters
173 We've now added new variants - set_rv() and set_multiple_rv() that return an
174 integer. Let's convert all GPIO drivers treewide to use the new callbacks,
177 -------------------------------------------------------------------------------
181 The need to support the sysfs GPIO class is one of the main obstacles to
182 removing the global GPIO numberspace from the kernel. In order to wean users
183 off using global numbers from user-space, extend the existing interface with
184 new per-gpiochip export/unexport attributes that allow to refer to GPIOs using
190 -------------------------------------------------------------------------------
195 that the GPIO descriptors (the software representation of the hardware concept)
196 are not reference counted and - in general - only one user at a time can
197 request a GPIO line and control its settings. The consumer API is designed
202 A problematic use-case for GPIOs is when two consumers want to use the same
203 descriptor independently. An example of such a user is the regulator subsystem
205 a struct device but using the same enable GPIO line.
207 A workaround was introduced in the form of the GPIOD_FLAGS_BIT_NONEXCLUSIVE
210 non-exclusive users of the same descriptor will in fact "fight" for the
211 control over it. This flag should be removed and replaced with a better
214 -------------------------------------------------------------------------------
218 devm_gpiod_unhinge() is provided as a way to transfer the ownership of managed
220 make it possible for the regulator subsystem to deal with GPIO resources the
221 lifetime of which it doesn't control as logically, a GPIO obtained by a caller