| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
This function was introduced as a workaround for an issue with resource
ownership in the regulator subsystem. Rather than passing the ownership
of a GPIO, we should make the regulator core be able to deal with
resources it didn't request. Deprecate this function so that we don't
get more users in the tree.
Link: https://lore.kernel.org/r/20250401-gpio-todo-remove-nonexclusive-v2-2-7c1380797b0d@linaro.org
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
There is no reason to keep deprecated legacy API implementations
in the gpiolib-devres.c. Consolidate devm_gpio_*() with other legacy
APIs. While at it, clean up header inclusion block in gpiolib-devres.c.
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ scripts/kernel-doc -v -none -Wall drivers/gpio/gpiolib* 2>&1 | grep -w warning | wc -l
67
Fix these by adding Return sections. While at it, make sure all of
Return sections use the same style.
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This devm API takes a consumer device as an argument to setup the devm
action, but throws it away when calling further into gpiolib. This leads
to odd debug messages like this:
(NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
Let's pass the consumer device down, by directly calling what
fwnode_gpiod_get_index() calls but pass the device used for devm. This
changes the message to look like this instead:
gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
Note that callers of fwnode_gpiod_get_index() will still see the NULL
device pointer debug message, but there's not much we can do about that
because the API doesn't take a struct device.
Cc: Dmitry Torokhov <[email protected]>
Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups")
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Now that everyone is using [devm_]fwnode_gpiod_get[_index]() APIs,
remove OF-specific [devm_]gpiod_get_from_of_node().
Signed-off-by: Dmitry Torokhov <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The last user, which in fact was a dead code, has gone a year ago,
previous one 3 years ago. On top of that we want to drop away the
legacy GPIO APIs in the kernel, so take a chance to get rid of
unused devm_gpio_free() and accompanying stuff.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Several gpiolib functions receive pointer to struct device_node which is
later passed to OF functions. These OF functions accept already pointer
to const, so gpiolib can follow similar approach to indicate they are
not modifying the struct device_node.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
If all we want to manage is a single pointer, there's no need to
manually allocate and add a new devres. We can simply use
devm_add_action_or_reset() and shrink the code by a good bit.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Several places in the code are using same idiom, i.e.
IS_ERR(desc) && PTR_ERR(desc) == -ENOENT
which meaning is GPIO description is not found.
For better readability extract gpiod_not_found() helper and use it.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents
in its commits message its intention to "create a unique class key for
each driver".
It does so by having gpiochip_add_data add in-place the definition of
two static lockdep classes for LOCKDEP use. That way, every caller of
the macro adds their gpiochip with unique lockdep classes.
There are many indirect callers of gpiochip_add_data, however, via
use of devm_gpiochip_add_data. devm_gpiochip_add_data has external
linkage and all its users will share the same lockdep classes, which
probably is not intended.
Fix this by replicating the gpio_chip_add_data statics-in-macro for
the devm_ version as well.
Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys")
Signed-off-by: Ahmad Fatoum <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
These two devres functions devm_gpiochip_[add|remove]()
were in the wrong file. They should be in gpiolib-devres.c
not gpiolib.c.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'PTR_ERR(p) == -E*' is a stronger condition than IS_ERR(p).
Hence, IS_ERR(p) is unneeded.
The semantic patch that generates this commit is as follows:
// <smpl>
@@
expression ptr;
constant error_code;
@@
-IS_ERR(ptr) && (PTR_ERR(ptr) == - error_code)
+PTR_ERR(ptr) == - error_code
// </smpl>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Masahiro Yamada <[email protected]>
Cc: Julia Lawall <[email protected]>
Acked-by: Stephen Boyd <[email protected]> [drivers/clk/clk.c]
Acked-by: Bartosz Golaszewski <[email protected]> [GPIO]
Acked-by: Wolfram Sang <[email protected]> [drivers/i2c]
Acked-by: Rafael J. Wysocki <[email protected]> [acpi/scan.c]
Acked-by: Rob Herring <[email protected]>
Cc: Eric Biggers <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces fwnode_gpiod_get_index() that iterates through common gpio
suffixes when trying to locate a GPIO within a given firmware node.
We also switch devm_fwnode_gpiod_get_index() to call
fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on
its own.
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mika Westerberg <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
devm_fwnode_get_index_gpiod_from_child() is too long, besides the fwnode
in question does not have to be a child of device node. Let's rename it
to devm_fwnode_gpiod_get_index() and keep the old name for compatibility
for now.
Also let's add a devm_fwnode_gpiod_get() wrapper as majority of the
callers need a single GPIO.
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Change all exported symbols for managed GPIO functions from
EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL(), like is used for their
non-managed counterparts.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a function named devm_gpiod_unhinge() that removes
the resource management from a GPIO descriptor.
I am not sure if this is the best anglosaxon name for the
function, no other managed resources have an equivalent
currently, but I chose "unhinge" as the closest intuitive
thing I could imagine that fits Rusty Russell's API design
criterions "the obvious use is the correct one" and
"the name tells you how to use it".
The idea came out of a remark from Mark Brown that it should
be possible to handle over management of a resource from
devres to the regulator core, and indeed we can do that.
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we get a nonexeclusive GPIO descriptor using managed
resources, we should only add it to the list of managed
resources once: on the first user. Augment the
devm_gpiod_get_index() and devm_gpiod_get_from_of_node()
calls to account for this by checking if the descriptor
is already resource managed before we proceed to allocate
a new resource management struct.
Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access")
Reported-by: Marek Szyprowski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Marek Szyprowski <[email protected]>
Tested-by: Marek Szyprowski <[email protected]>
Reviewed-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
|
|
|
All the other core files are named "gpiolib-<something>" so
let's rename the devres as well so we have some logical
namespacing here.
Signed-off-by: Linus Walleij <[email protected]>
|
