drivers/gpio/TODO

Source file repositories/reference/linux-study-clean/drivers/gpio/TODO

File Facts

System
Linux kernel
Corpus path
drivers/gpio/TODO
Extension
[no extension]
Size
7828 bytes
Lines
175
Domain
Driver Families
Bucket
drivers/gpio
Inferred role
Driver Families: drivers/gpio
Status
atlas-only

Why This File Exists

Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.

Dependency Surface

Detected Declarations

Annotated Snippet

This is a place for planning the ongoing long-term work in the GPIO
subsystem.

===============================================================================

GPIO descriptors

Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey
to move away from the global GPIO numberspace and toward a descriptor-based
approach. This means that GPIO consumers, drivers and machine descriptions
ideally have no use or idea of the global GPIO numberspace that has/was
used in the inception of the GPIO subsystem.

The numberspace issue is the same as to why irq is moving away from irq
numbers to IRQ descriptors.

The underlying motivation for this is that the GPIO numberspace has become
unmanageable: machine board files tend to become full of macros trying to
establish the numberspace at compile-time, making it hard to add any numbers
in the middle (such as if you missed a pin on a chip) without the numberspace
breaking.

Machine descriptions such as device tree or ACPI does not have a concept of the
Linux GPIO number as those descriptions are external to the Linux kernel
and treat GPIO lines as abstract entities.

The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
base as -1 in struct gpio_chip) has also became unpredictable due to factors
such as probe ordering and the introduction of -EPROBE_DEFER making probe
ordering of independent GPIO chips essentially unpredictable, as their base
number will be assigned on a first come first serve basis.

The best way to get out of the problem is to make the global GPIO numbers
unimportant by simply not using them. GPIO descriptors deal with this.

Work items:

- Convert all GPIO device drivers to only #include <linux/gpio/driver.h>

- Convert all consumer drivers to only #include <linux/gpio/consumer.h>

- Convert all machine descriptors in "boardfiles" to only
  #include <linux/gpio/machine.h>, the other option being to convert it
  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.

-------------------------------------------------------------------------------

Collect drivers

Collect GPIO drivers from arch/* and other places that should be placed
in drivers/gpio/gpio-*. Augment platforms to create platform devices or
similar and probe a proper driver in the gpiolib subsystem.

In some cases it makes sense to create a GPIO chip from the local driver
for a few GPIOs. Those should stay where they are.

At the same time it makes sense to get rid of code duplication in existing or

Annotation

Implementation Notes