kernel/Documentation/driver-api/gpio/board.rst, branch linux-rolling-stable

Documentation: gpio: add documentation about using software nodes

2025-08-26T13:27:04Z

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

gpio: Remove legacy API documentation

2024-05-27T14:50:03Z

In order to discourage people to use old and legacy GPIO APIs remove the respective documentation completely. It also helps further cleanups of the legacy GPIO API leftovers, which is ongoing task. Signed-off-by: Andy Shevchenko Reviewed-by: Hu Haowen <2023002089@link.tyut.edu.cn> Link: https://lore.kernel.org/r/20240508101703.830066-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski

docs: driver-api: gpio: Fix filename mismatch

2022-06-13T16:12:24Z

The filenames were changed a while ago, but board.rst, consumer.rst and intro.rst still refer to the old names. Fix those references to match the Actual names and avoid possible confusion. Signed-off-by: Tom Schwindl Signed-off-by: Bartosz Golaszewski

ACPI: docs: gpio-properties: Unify ASL style for GPIO examples

2022-03-08T19:04:51Z

GPIO examples of ASL in the board.rst, enumeration.rst and gpio-properties.rst are not unified. Unify them for better reader experience. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki

gpiolib: Add support for GPIO lookup by line name

2020-05-18T08:12:42Z

Currently a GPIO lookup table can only refer to a specific GPIO by a tuple, consisting of a GPIO controller label and a GPIO offset inside the controller. However, a GPIO may also carry a line name, defined by DT or ACPI. If present, the line name is the most use-centric way to refer to a GPIO. Hence add support for looking up GPIOs by line name. Note that there is no guarantee that GPIO line names are globally unique, so this will use the first match found. Implement this by reusing the existing gpiod_lookup infrastructure. Rename gpiod_lookup.chip_label to gpiod_lookup.key, to make it clear that this field can have two meanings, and update the kerneldoc and GPIO_LOOKUP*() macros. Signed-off-by: Geert Uytterhoeven Tested-by: Eugeniu Rosca Reviewed-by: Ulrich Hecht Reviewed-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20200511145257.22970-4-geert+renesas@glider.be Signed-off-by: Linus Walleij

docs: fix broken documentation links

2019-06-08T19:42:13Z

Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Wolfram Sang Reviewed-by: Sven Van Asbroeck Reviewed-by: Bhupesh Sharma Acked-by: Mark Brown Signed-off-by: Jonathan Corbet

Documenation: driver-api: fix gpio/board.rst warning

2019-02-11T08:09:44Z

Fix markup warning: insert a blank line before the list. Documentation/driver-api/gpio/board.rst:209: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: linux-gpio@vger.kernel.org Signed-off-by: Linus Walleij

gpiolib: Fix array members of same chip processed separately

2018-09-24T11:47:05Z

New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays matching GPIO hardware") forcibly tries to find an array member which has its array index number equal to its hardware pin number and set up an array info for possible fast bitmap processing of all arrray pins belonging to that chip which also satisfy that numbering rule. Depending on array content, it may happen that consecutive array members which belong to the same chip but don't have array indexes equal to their pin hardware numbers will be split into groups, some of them processed together via the fast bitmap path, and rest of them separetely. However, applications may expect all those pins being processed together with a single call to .set_multiple() chip callback, like that was done before the change. Limit applicability of fast bitmap processing path to cases where all pins of consecutive array members starting from 0 which belong to the same chip have their hardware numbers equal to their corresponding array indexes. That should still speed up processing of applications using whole GPIO banks as I/O ports, while not breaking simultaneous manipulation of consecutive pins of the same chip which don't follow the equal numbering rule. Cc: Jonathan Corbet Signed-off-by: Janusz Krzysztofik Tested-by: Marek Szyprowski Signed-off-by: Linus Walleij

gpiolib: Implement fast processing path in get/set array

2018-09-13T09:17:23Z

Certain GPIO descriptor arrays returned by gpio_get_array() may contain information on direct mapping of array members to pins of a single GPIO chip in hardware order. In such cases, bitmaps of values can be passed directly from/to the chip's .get/set_multiple() callbacks without wasting time on iterations. Add respective code to gpiod_get/set_array_bitmap_complex() functions. Pins not applicable for fast path are processed as before, skipping over the 'fast' ones. Cc: Jonathan Corbet Signed-off-by: Janusz Krzysztofik Signed-off-by: Linus Walleij

gpiolib: add hogs support for machine code

2018-05-16T12:35:24Z

Board files constitute a significant part of the users of the legacy GPIO framework. In many cases they only export a line and set its desired value. We could use GPIO hogs for that like we do for DT and ACPI but there's no support for that in machine code. This patch proposes to extend the machine.h API with support for registering hog tables in board files. Signed-off-by: Bartosz Golaszewski Signed-off-by: Linus Walleij