kernel/linux.git/include/linux/gpio/machine.h, branch v6.6.132

gpiolib: Clean up headers

2022-10-24T09:30:26+00:00

There is a few things done: - include only the headers we are direct user of - when pointer is in use, provide a forward declaration - add missing headers - group generic headers and subsystem headers - sort each group alphabetically While at it, fix some awkward indentations. Signed-off-by: Andy Shevchenko

gpiolib: add support for bias pull disable

2022-07-19T08:23:54+00:00

This change prepares the gpio core to look at firmware flags and set 'FLAG_BIAS_DISABLE' if necessary. It works in similar way to 'GPIO_PULL_DOWN' and 'GPIO_PULL_UP'. Signed-off-by: Nuno Sá Signed-off-by: Bartosz Golaszewski

ARM/pxa/mfd/power/sound: Switch Tosa to GPIO descriptors

2022-05-07T20:55:33+00:00

The Tosa device (Sharp SL-6000) has a mishmash driver set-up for the Toshiba TC6393xb MFD that includes a battery charger and touchscreen and has some kind of relationship to the SoC sound driver for the AC97 codec. Other devices define a chip like this but seem only half-implemented, not really handling battery charging etc. This patch switches the Toshiba MFD device to provide GPIO descriptors to the battery charger and SoC codec. As a result some descriptors need to be moved out of the Tosa boardfile and new one added: all SoC GPIO resources to these drivers now comes from the main boardfile, while the MFD provide GPIOs for its portions. As a result we can request one GPIO from our own GPIO chip and drop two hairy callbacks into the board file. This platform badly needs to have its drivers split up and converted to device tree probing to handle this quite complex relationship in an orderly manner. I just do my best in solving the GPIO descriptor part of the puzzle. Please don't ask me to fix everything that is wrong with these driver to todays standards, I am just trying to fix one aspect. I do try to use modern devres resource management and handle deferred probe using new functions where appropriate. Cc: Dmitry Eremin-Solenikov Cc: Dirk Opfer Cc: Robert Jarzmik Cc: Daniel Mack Cc: Haojian Zhuang Cc: Lee Jones Cc: Liam Girdwood Reviewed-by: Dmitry Baryshkov Acked-by: Mark Brown Acked-by: Sebastian Reichel Signed-off-by: Linus Walleij Signed-off-by: Arnd Bergmann

gpiolib: provide gpiod_remove_hogs()

2021-12-17T11:26:12+00:00

Currently all users of gpiod_add_hogs() call it only once at system init so there never was any need for a mechanism allowing to remove them. Now the upcoming gpio-sim will need to tear down chips with hogged lines so provide a function that allows to remove hogs. Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij

gpio: aggregator: Use compound literal from the header

2021-02-15T10:43:32+00:00

Instead of doing it in place, convert GPIO_LOOKUP_IDX() and GPIO_HOG() to be compund literals that's allow to use them as rvalue in assignments. Due to above conversion, use compound literal from the header in the gpio-aggregator.c. Signed-off-by: Andy Shevchenko Reviewed-by: Geert Uytterhoeven

gpiolib: Add support for GPIO lookup by line name

2020-05-18T08:12:42+00:00

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

gpio: Add comments on #if/#else/#endif

2019-06-27T14:56:50+00:00

Improve readability a bit by commenting #if/#else/#endif statements with the checked preprocessor symbols. Signed-off-by: Enrico Weigelt Signed-off-by: Linus Walleij

gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT

2019-04-23T08:55:10+00:00

Since GPIO library operates with enumerator when it's subject to handle the GPIO lookup flags, it will be better to clearly see what default means. Thus, introduce GPIO_LOOKUP_FLAGS_DEFAULT entry to describe the default assumptions. While here, replace 0 by newly introduced constant. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij

gpiolib: Make use of enum gpio_lookup_flags consistent

2019-04-23T08:55:07+00:00

The library uses enum gpio_lookup_flags to define the possible characteristics of GPIO pin. Since enumerator listed only individual bits the common use of it is in a form of a bitmask of gpio_lookup_flags GPIO_* values. The more correct type for this is unsigned long. Due to above convert all users to use unsigned long instead of enum gpio_lookup_flags except enumerator definition. While here, make field and parameter descriptions consistent as well. Suggested-by: Mika Westerberg Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij

gpiolib: Indent entry values of enum gpio_lookup_flags

2019-04-23T08:54:42+00:00

Indent entry values in the enum gpio_lookup_flags for better readability. No functional change. Signed-off-by: Andy Shevchenko Acked-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij