linux-toradex.git/Documentation/driver-api/gpio, branch master

gpiolib: add get_config() and gpiochip_generic_get_config()

2026-09-21T09:14:49+00:00

A chip with a pin control backend sets a line's configuration through
set_config() and gpiochip_generic_config(), but has no way to read one
back. gpio-mmio needs that to learn the direction of a line whose
direction lives in the pin controller.

Add the optional get_config() callback, taking the packed parameter to
query and returning its bare argument the way pinctrl_gpio_get_config()
does, and gpiochip_generic_get_config() as the pin control backed
implementation, the mirror of gpiochip_generic_config(): a chip without
pin ranges, or a kernel without pinctrl, gets -ENOTSUPP.

Nothing in gpiolib calls get_config() and there is no consumer API; it
is for the chip's own use.

Suggested-by: Linus Walleij 
Signed-off-by: Mehmet Fide 
Reviewed-by: Linus Walleij 
Link: https://patch.msgid.link/20260915080501.329424-4-mehmet.fide@gmail.com
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: Fix bracket

2026-09-07T08:37:15+00:00

Balance parentheses.

Signed-off-by: Manuel Ebner 
Acked-by: Randy Dunlap 
Link: https://patch.msgid.link/20260903155345.733244-2-manuelebnerli@mailbox.org
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: update the preferred method for using software node lookup

2026-04-08T13:52:26+00:00

In its current version, the manual for converting of board files from
using GPIO lookup tables to software nodes recommends leaving the
software nodes representing GPIO controllers as "free-floating", not
attached objects and relying on the matching of their names against the
GPIO controller's name. This is an abuse of the software node API and
makes it impossible to create fw_devlinks between GPIO suppliers and
consumers in this case. We want to remove this behavior from GPIOLIB and
to this end, work on converting all existing drivers to using "attached"
software nodes.

Except for a few corner-cases where board files define consumers
depending on GPIO controllers described in firmware - where we need to
reference a real firmware node from a software node - which requires a
more complex approach, most board files can easily be converted to using
propert firmware node lookup.

Update the documentation to recommend attaching the GPIO chip's software
nodes to the actual platform devices and show how to do it.

Reviewed-by: Linus Walleij 
Link: https://patch.msgid.link/20260403-doc-gpio-swnodes-v2-1-c705f5897b80@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski

gpio: remove machine hogs

2026-03-16T08:51:06+00:00

With no more users, remove legacy machine hog API from the kernel.

Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
Link: https://patch.msgid.link/20260309-gpio-hog-fwnode-v2-5-4e61f3dbf06a@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski

gpio: Document line value semantics

2026-03-09T09:16:00+00:00

It is not clearly documented that the GPIO driver API expect the
driver to get/set the physical level of the GPIO line and the
consumer API will get/set the logic level. Document this in
relevant places.

Reported-by: David Jander 
Signed-off-by: Linus Walleij 
Link: https://patch.msgid.link/20260306-gpio-doc-levels-v1-1-19928739e400@kernel.org
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: pca953x: clarify interrupt source detection

2026-01-08T09:50:33+00:00

There are multiple design tradeoffs and considerations in how the
PCA953x driver detects the source(s) of an interrupt. This driver
supports PCAL variants with input latching, a feature that is
constrained by the fact that the interrupt status and input port
registers cannot be read atomically. These limits and the design
decisions deserve an in-depth explanation.

Update the documentation to clarify these hardware limits and describe
how the driver determines pending interrupts, and how it makes use of
the PCAL input latching.

Signed-off-by: Ernest Van Hoecke 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20260107093125.4053468-1-ernestvanhoecke@gmail.com
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: add TCAL6408 and TCAL6416

2025-12-18T10:27:05+00:00

Checked datasheets, the offsets are identical to pcal6408 and pcal6416.

Signed-off-by: Jan Remmet 
Link: https://lore.kernel.org/r/20251216-wip-jremmet-tcal6416rtw-v2-1-6516d98a9836@phytec.de
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: Add a compatibility and feature list for PCA953x

2025-11-19T11:07:39+00:00

I went through all the datasheets and created this note listing
chip functions and register layouts.

Signed-off-by: Levente Révész 
Signed-off-by: Andy Shevchenko 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
Reviewed-by: Linus Walleij 
Reviewed-by: Bagas Sanjaya 
Link: https://lore.kernel.org/r/20251112224924.2091880-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Bartosz Golaszewski

Documentation: gpio: add documentation about using software nodes

2025-08-26T13:27:04+00:00

Introduce documentation regarding use of software nodes to describe
GPIOs on legacy boards that have not been converted to device tree.

Reviewed-by: Randy Dunlap 
Tested-by: Randy Dunlap 
Signed-off-by: Dmitry Torokhov 
Reviewed-by: Linus Walleij 
Link: https://lore.kernel.org/r/tnaaz2qlk5jpbonfle7uy7pb54qx6ixwuczfbkwtxxwpj7hwas@y7a2rwko3k6c
Signed-off-by: Bartosz Golaszewski

Documentation: treewide: Replace remaining spinics links with lore

2025-06-21T20:20:51+00:00

Long before introduction of lore.kernel.org, people would link
to LKML threads on third-party archives (here spinics.net), which
in some cases can be unreliable (as these were outside of
kernel.org control). Replace links to them with lore counterparts
(if any).

Signed-off-by: Bagas Sanjaya 
Reviewed-by: Simon Horman 
Signed-off-by: Jonathan Corbet 
Link: https://lore.kernel.org/r/20250611065254.36608-2-bagasdotme@gmail.com