gpiolib: fix kerneldoc

Add missing '@' to the kernel doc for the new of_node_instance_match
field of struct gpio_chip.

Fixes: bd3ce71078bd ("gpiolib: of: Handle threecell GPIO chips")
Reported-by:

gpiolib: fix kerneldoc

Add missing '@' to the kernel doc for the new of_node_instance_match
field of struct gpio_chip.

Fixes: bd3ce71078bd ("gpiolib: of: Handle threecell GPIO chips")
Reported-by: Stephen Rothwell <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: Hide valid_mask from direct assignments

The valid_mask member of the struct gpio_chip is unconditionally written
by the GPIO core at driver registration. Current documentation does not
mention

gpio: Hide valid_mask from direct assignments

The valid_mask member of the struct gpio_chip is unconditionally written
by the GPIO core at driver registration. Current documentation does not
mention this but just says the valid_mask is used if it's not NULL. This
lured me to try populating it directly in the GPIO driver probe instead
of using the init_valid_mask() callback. It took some retries with
different bitmaps and eventually a bit of code-reading to understand why
the valid_mask was not obeyed. I could've avoided this trial and error if
the valid_mask was hidden in the struct gpio_device instead of being a
visible member of the struct gpio_chip.

Help the next developer who decides to directly populate the valid_mask
in struct gpio_chip by hiding the valid_mask in struct gpio_device and
keep it internal to the GPIO core.

Suggested-by: Linus Walleij <[email protected]>
Signed-off-by: Matti Vaittinen <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/4547ca90d910d60cab3d56d864d59ddde47a5e93.1741180097.git.mazziesaccount@gmail.com
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: Add a valid_mask getter

The valid_mask member of the struct gpio_chip is unconditionally written
by the GPIO core at driver registration. It shouldn't be directly
populated by drivers. This ca

gpio: Add a valid_mask getter

The valid_mask member of the struct gpio_chip is unconditionally written
by the GPIO core at driver registration. It shouldn't be directly
populated by drivers. This can be prevented by moving it from the struct
gpio_chip to struct gpio_device, which is internal to the GPIO core.

As a preparatory step, provide a getter function which can be used by
those drivers which need the valid_mask information.

Signed-off-by: Matti Vaittinen <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/026f9d78502eca883bfe3faeb684e23d5d6c5e84.1741180097.git.mazziesaccount@gmail.com
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: of: Handle threecell GPIO chips

When describing GPIO controllers in the device tree, the ambition
of device tree to describe the hardware may require a three-cell
scheme:

gpios = <&gpio in

gpiolib: of: Handle threecell GPIO chips

When describing GPIO controllers in the device tree, the ambition
of device tree to describe the hardware may require a three-cell
scheme:

gpios = <&gpio instance offset flags>;

This implements support for this scheme in the gpiolib OF core.

Drivers that want to handle multiple gpiochip instances from one
OF node need to implement a callback similar to this to
determine if a certain gpio chip is a pointer to the right
instance (pseudo-code):

struct my_gpio {
struct gpio_chip gcs[MAX_CHIPS];
};

static bool my_of_node_instance_match(struct gpio_chip *gc
unsigned int instance)
{
struct my_gpio *mg = gpiochip_get_data(gc);

if (instance >= MAX_CHIPS)
return false;
return (gc == &mg->gcs[instance]);
}

probe() {
struct my_gpio *mg;
struct gpio_chip *gc;
int i, ret;

for (i = 0; i++; i < MAX_CHIPS) {
gc = &mg->gcs[i];
/* This tells gpiolib we have several instances per node */
gc->of_gpio_n_cells = 3;
gc->of_node_instance_match = my_of_node_instance_match;
gc->base = -1;
...

ret = devm_gpiochip_add_data(dev, gc, mg);
if (ret)
return ret;
}
}

Rename the "simple" of_xlate function to "twocell" which is closer
to what it actually does.

In the device tree bindings, the provide node needs
to specify #gpio-cells = <3>; where the first cell is the instance
number:

gpios = <&gpio instance offset flags>;

Conversely ranges need to have four cells:

gpio-ranges = <&pinctrl instance gpio_offset pin_offset count>;

Reviewed-by: Alex Elder <[email protected]>
Tested-by: Yixun Lan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Reviewed-by: Rob Herring (Arm) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: deprecate gpio_chip::set and gpio_chip::set_multiple

We now have setter callbacks that allow us to indicate success or
failure using the integer return value. Deprecate the older callbacks

gpiolib: deprecate gpio_chip::set and gpio_chip::set_multiple

We now have setter callbacks that allow us to indicate success or
failure using the integer return value. Deprecate the older callbacks so
that no new code is tempted to use them.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: introduce gpio_chip setters that return values

Add new variants of the set() and set_multiple() callbacks that have
integer return values allowing to indicate failures to users of the GPIO

gpiolib: introduce gpio_chip setters that return values

Add new variants of the set() and set_multiple() callbacks that have
integer return values allowing to indicate failures to users of the GPIO
consumer API. Until we convert all GPIO providers treewide to using
them, they will live in parallel to the existing ones.

Make sure that providers cannot define both. Prefer the new ones and
only use the old ones as fallback.

Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: mmio: Add flag for calling pinctrl back-end

It turns out that with this flag we can switch over an entire
driver to use gpio-mmio instead of a bunch of custom code,
also providing get/set_mult

gpio: mmio: Add flag for calling pinctrl back-end

It turns out that with this flag we can switch over an entire
driver to use gpio-mmio instead of a bunch of custom code,
also providing get/set_multiple() to it in the process, so it
seems like a reasonable feature to add.

The generic pin control backend requires us to call the
gpiochip_generic_request(), gpiochip_generic_free(),
pinctrl_gpio_direction_output() and pinctrl_gpio_direction_input()
callbacks, so if the new flag for a pin control back-end
is set, we make sure these functions get called as
expected.

Signed-off-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: sanitize the return value of gpio_chip::set_config()

The return value of the set_config() callback may be propagated to
user-space. If a bad driver returns a positive number, it may confuse

gpiolib: sanitize the return value of gpio_chip::set_config()

The return value of the set_config() callback may be propagated to
user-space. If a bad driver returns a positive number, it may confuse
user programs. Tighten the API contract and check for positive numbers
returned by GPIO controllers.

Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: sanitize the return value of gpio_chip::request()

The return value of the request() callback may be propagated to
user-space. If a bad driver returns a positive number, it may confuse
user

gpiolib: sanitize the return value of gpio_chip::request()

The return value of the request() callback may be propagated to
user-space. If a bad driver returns a positive number, it may confuse
user programs. Tighten the API contract and check for positive numbers
returned by GPIO controllers.

Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Switch to use for_each_if() helper

The for_each_*() APIs that are conditional can be written shorter and
less error prone with for_each_if() helper in use. Switch them to use
this helper.

gpiolib: Switch to use for_each_if() helper

The for_each_*() APIs that are conditional can be written shorter and
less error prone with for_each_if() helper in use. Switch them to use
this helper.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Simplify implementation of for_each_hwgpio_in_range()

The whole purpose of the custom CLASS() is to have possibility
to initialise the counter variable _i to 0. This can't be done
with simp

gpiolib: Simplify implementation of for_each_hwgpio_in_range()

The whole purpose of the custom CLASS() is to have possibility
to initialise the counter variable _i to 0. This can't be done
with simple __free() macro as it will be not allowed by C language.
OTOH, the CLASS() operates with the pointers and explicit usage of
the scoped variable _data is not needed, since the pointers are kept
the same over the iterations. Simplify the implementation of
for_each_hwgpio_in_range().

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Deduplicate some code in for_each_requested_gpio_in_range()

Refactor for_each_requested_gpio_in_range() to deduplicate some code
which is basically repeats the for_each_hwgpio(). In order t

gpiolib: Deduplicate some code in for_each_requested_gpio_in_range()

Refactor for_each_requested_gpio_in_range() to deduplicate some code
which is basically repeats the for_each_hwgpio(). In order to achieve
this, split the latter to two, for_each_hwgpio_in_range() and
for_each_hwgpio().

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: unexport gpiochip_get_desc()

This function has been deprecated for some time and is now only used
within the GPIOLIB core. Remove it from the public header and unexport
it as all current us

gpiolib: unexport gpiochip_get_desc()

This function has been deprecated for some time and is now only used
within the GPIOLIB core. Remove it from the public header and unexport
it as all current users are linked against the compilation unit where
it is defined.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Remove data-less gpiochip_add() function

GPIO chips should be added with driver-private data associated with the
chip. If none is needed, NULL can be used. All users already do this
except

gpiolib: Remove data-less gpiochip_add() function

GPIO chips should be added with driver-private data associated with the
chip. If none is needed, NULL can be used. All users already do this
except one, fix that here. With no more users of the base gpiochip_add()
we can drop this function so no more users show up later.

Signed-off-by: Andrew Davis <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Discourage to use formatting strings in line names

Currently the documentation for line names allows to use %u inside
the alternative name. This is broken in character device approach
from

gpiolib: Discourage to use formatting strings in line names

Currently the documentation for line names allows to use %u inside
the alternative name. This is broken in character device approach
from day 1 and being in use solely in sysfs.

Character device interface has a line number as a part of its address,
so the users better rely on it. Hence remove the misleading documentation.

On top of that, there are no in-kernel users (out of 6, if I'm correct)
for such names and moreover if one exists it won't help in distinguishing
lines with the same naming as '%u' will also be in them and we will get
a warning in gpiochip_set_desc_names() for such cases.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Kent Gibson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Add stubs for GPIO lookup functions

The gpio_device_find_by_() functions do not have stubs which means that if
they are referenced from code with an optiona dependency on gpiolib then
the c

gpiolib: Add stubs for GPIO lookup functions

The gpio_device_find_by_() functions do not have stubs which means that if
they are referenced from code with an optiona dependency on gpiolib then
the code will fail to link. Add stubs for lookups via fwnode and label. I
have not added a stub for plain gpio_device_find() since it seems harder to
see a use case for that which does not depend on gpiolib.

With the addition of the GPIO reset controller (which lacks a gpiolib
dependency) to the arm64 defconfig this is causing build breaks for arm64
virtconfig in -next:

aarch64-linux-gnu-ld: drivers/reset/core.o: in function `__reset_add_reset_gpio_lookup':
/build/stage/linux/drivers/reset/core.c:861:(.text+0xccc): undefined reference to `gpio_device_find_by_fwnode'

Signed-off-by: Mark Brown <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: provide for_each_hwgpio()

We only provide iterators for requested GPIOs to provider drivers. In
order to allow them to display debug information about all GPIOs, let's
provide a variant for it

gpio: provide for_each_hwgpio()

We only provide iterators for requested GPIOs to provider drivers. In
order to allow them to display debug information about all GPIOs, let's
provide a variant for iterating over all GPIOs.

Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>

show more ...

gpio: constify opaque pointer "data" in gpio_device_find()

The opaque pointer "data" in each match function used by
gpio_device_find() is a pointer to const, thus the same argument passed
to gpio_de

gpio: constify opaque pointer "data" in gpio_device_find()

The opaque pointer "data" in each match function used by
gpio_device_find() is a pointer to const, thus the same argument passed
to gpio_device_find() can adjusted similarly.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: add gpio_device_get_label() stub for !GPIOLIB

Add empty stub of gpio_device_get_label() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: d1f7728259ef ("gpiolib: provide gpi

gpiolib: add gpio_device_get_label() stub for !GPIOLIB

Add empty stub of gpio_device_get_label() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: d1f7728259ef ("gpiolib: provide gpio_device_get_label()")
Suggested-by: kernel test robot <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: add gpio_device_get_base() stub for !GPIOLIB

Add empty stub of gpio_device_get_base() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: 8c85a102fc4e ("gpiolib: provide gpio_

gpiolib: add gpio_device_get_base() stub for !GPIOLIB

Add empty stub of gpio_device_get_base() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: 8c85a102fc4e ("gpiolib: provide gpio_device_get_base()")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: add gpiod_to_gpio_device() stub for !GPIOLIB

Add empty stub of gpiod_to_gpio_device() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: 370232d096e3 ("gpiolib: provide gpiod

gpiolib: add gpiod_to_gpio_device() stub for !GPIOLIB

Add empty stub of gpiod_to_gpio_device() when GPIOLIB is not enabled.

Cc: <[email protected]>
Fixes: 370232d096e3 ("gpiolib: provide gpiod_to_gpio_device()")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: constify opaque pointer in gpio_device_find() match function

The match function used in gpio_device_find() should not modify the
contents of passed opaque pointer, because such modification wo

gpio: constify opaque pointer in gpio_device_find() match function

The match function used in gpio_device_find() should not modify the
contents of passed opaque pointer, because such modification would not
be necessary for actual matching and it could lead to quite unreadable,
spaghetti code.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
[Bartosz: fix coding style in header]
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpio: improve the API contract for setting direction

If a GPIO driver returns a positive integer from one of the direction
setter callbacks, we'll end up propagating it to user-space. Whether we
sho

gpio: improve the API contract for setting direction

If a GPIO driver returns a positive integer from one of the direction
setter callbacks, we'll end up propagating it to user-space. Whether we
should sanitize the values returned by callbacks is a different question
but let's first improve the documentation and fortify the contract with
GPIO providers.

Reported-by: José Guilherme de Castro Rodrigues <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Kent Gibson <[email protected]>

show more ...

gpio: unexport GPIO irq domain functions only used internally

There are no external users for the irq domain helpers so unexport them
and remove the prototypes from the driver header.

Signed-off-by

gpio: unexport GPIO irq domain functions only used internally

There are no external users for the irq domain helpers so unexport them
and remove the prototypes from the driver header.

Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...

gpiolib: Fix scope-based gpio_device refcounting

Commit 9e4555d1e54a ("gpiolib: add support for scope-based management to
gpio_device") sought to add scope-based gpio_device refcounting, but
erroneo

gpiolib: Fix scope-based gpio_device refcounting

Commit 9e4555d1e54a ("gpiolib: add support for scope-based management to
gpio_device") sought to add scope-based gpio_device refcounting, but
erroneously forgot a negation of IS_ERR_OR_NULL().

As a result, gpio_device_put() is not called if the gpio_device pointer
is valid (meaning the ref is leaked), but only called if the pointer is
NULL or an ERR_PTR().

While at it drop a superfluous trailing semicolon.

Fixes: 9e4555d1e54a ("gpiolib: add support for scope-based management to gpio_device")
Signed-off-by: Lukas Wunner <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>

show more ...