@@ -10,6 +10,28 @@ approach. This means that GPIO consumers, drivers and machine descriptions
10
10
ideally have no use or idea of the global GPIO numberspace that has/was
11
11
used in the inception of the GPIO subsystem.
12
12
13
+ The numberspace issue is the same as to why irq is moving away from irq
14
+ numbers to IRQ descriptors.
15
+
16
+ The underlying motivation for this is that the GPIO numberspace has become
17
+ unmanageable: machine board files tend to become full of macros trying to
18
+ establish the numberspace at compile-time, making it hard to add any numbers
19
+ in the middle (such as if you missed a pin on a chip) without the numberspace
20
+ breaking.
21
+
22
+ Machine descriptions such as device tree or ACPI does not have a concept of the
23
+ Linux GPIO number as those descriptions are external to the Linux kernel
24
+ and treat GPIO lines as abstract entities.
25
+
26
+ The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
27
+ base as -1 in struct gpio_chip) has also became unpredictable due to factors
28
+ such as probe ordering and the introduction of -EPROBE_DEFER making probe
29
+ ordering of independent GPIO chips essentially unpredictable, as their base
30
+ number will be assigned on a first come first serve basis.
31
+
32
+ The best way to get out of the problem is to make the global GPIO numbers
33
+ unimportant by simply not using them. GPIO descriptors deal with this.
34
+
13
35
Work items:
14
36
15
37
- Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
@@ -33,7 +55,7 @@ This header and helpers appeared at one point when there was no proper
33
55
driver infrastructure for doing simpler MMIO GPIO devices and there was
34
56
no core support for parsing device tree GPIOs from the core library with
35
57
the [devm_]gpiod_get() calls we have today that will implicitly go into
36
- the device tree back-end.
58
+ the device tree back-end. It is legacy and should not be used in new code.
37
59
38
60
Work items:
39
61
@@ -59,6 +81,15 @@ Work items:
59
81
uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
60
82
61
83
84
+ Get rid of <linux/gpio.h>
85
+
86
+ This legacy header is a one stop shop for anything GPIO is closely tied
87
+ to the global GPIO numberspace. The endgame of the above refactorings will
88
+ be the removal of <linux/gpio.h> and from that point only the specialized
89
+ headers under <linux/gpio/*.h> will be used. This requires all the above to
90
+ be completed and is expected to take a long time.
91
+
92
+
62
93
Collect drivers
63
94
64
95
Collect GPIO drivers from arch/* and other places that should be placed
@@ -109,7 +140,7 @@ try to cover any generic kind of irqchip cascaded from a GPIO.
109
140
110
141
int irq; /* from platform etc */
111
142
struct my_gpio *g;
112
- struct gpio_irq_chip *girq
143
+ struct gpio_irq_chip *girq;
113
144
114
145
/* Set up the irqchip dynamically */
115
146
g->irq.name = "my_gpio_irq";
@@ -137,9 +168,14 @@ try to cover any generic kind of irqchip cascaded from a GPIO.
137
168
- Look over and identify any remaining easily converted drivers and
138
169
dry-code conversions to gpiolib irqchip for maintainers to test
139
170
140
- - Support generic hierarchical GPIO interrupts: these are for the
141
- non-cascading case where there is one IRQ per GPIO line, there is
142
- currently no common infrastructure for this.
171
+ - Drop gpiochip_set_chained_irqchip() when all the chained irqchips
172
+ have been converted to the above infrastructure.
173
+
174
+ - Add more infrastructure to make it possible to also pass a threaded
175
+ irqchip in struct gpio_irq_chip.
176
+
177
+ - Drop gpiochip_irqchip_add_nested() when all the chained irqchips
178
+ have been converted to the above infrastructure.
143
179
144
180
145
181
Increase integration with pin control
0 commit comments