The C extension methods request_set_values() and request_get_values()
iterate over a caller-supplied sequence and write offsets/values into
pre-allocated buffers self->offsets and self->values, without checking
the write index.
If the user tries to read values for more lines than they previously
requested, we overflow the buffers.
Add appropriate bounds checks and implement test cases for this issue.
Fixes: b7ba732e6a ("treewide: libgpiod v2 implementation")
Reported-by: 4fqr <4fqr@proton.me>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Reviewed-by: Vincent Fazio <vfazio@xes-inc.com>
Link: https://patch.msgid.link/20260407-treewide-fixes-v1-1-66c9744a56a3@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Previously, the bindings called out the SPDX license identifier in the
pyproject.toml but did not include a copy of the license in either the
source or binary distributions.
This can be problematic for tools that rely on extracting license
information, such as Buildroot or other license auditing mechanisms.
Now, when distributions are built, the license is copied out of the
libgpiod source tarball and into the target distribution.
Closes: https://github.com/brgl/libgpiod/issues/162
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://patch.msgid.link/20260228184158.25003-1-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
For lines with no name, chip_get_line_name() returns Py_None but does
not increment its reference count. Do it enough times and the following
error will occur with cpython before v3.12:
Fatal Python error: none_dealloc: deallocating None: bug likely caused by a refcount error in a C extension
Add the missing Py_INCREF(). It's safe to do even on python >= v3.12 as
Py_INCREF() has no effect on immortal objects in more recent versions.
Fixes: 0c0993569c ("bindings: python: ext: add ability to query line name")
Reported-by: Pierre Gramme <pgramme@gmail.com>
Closes: https://github.com/brgl/libgpiod/issues/166
Link: https://lore.kernel.org/r/20260113092852.42573-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Changelog:
- make request and reconfigure behavior for lines requested by names
consistent with that of lines requested by offsets
- fix parsing non-tuple keys when requesting a line
- disable UP045 linter check
- use quoted types when casting
- generate wheels for CPython 3.14
- issue a warning when reconfiguring a line not in the original request
- update dependencies for wheel generation
- update licensing information
- coding style fixes
- minor performance improvements
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Previously, lines requested by name could also be referred to by offset
when calling LineRequest.reconfigure_lines. However, lines requested by
offset could not be reconfigured by name if they had one.
Now, the name map is populated if the line has a name regardless of if
it's requested by name or offset.
To make behavior as consistent with earlier versions as possible, a line
requested by name always returns the first line on the chip with that
name. If there are duplicate line names and lines are requested by
offset, the first line in the request is mapped to the name. A line
requested by name always overrides a name mapped via an offset request.
If lines 0-3 all have the same name and a config object looks like:
{("foo", 1, 2): None}
or
{(1, "foo", 2): None}
Then lines 0-2 are requested and line 0 can be reconfigured by name.
If the config object looks like:
{(1, 2): None}
Then lines 1 and 2 are requested and line 1 can be reconfigured by name.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251009130516.3729433-9-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Previously, calling `reconfigure_lines` with line identifiers that were
not included in the original request produced different behaviors
depending on the identifier type.
If the identifier was an integer, it would be silently ignored.
If the identifier was a string, it would raise a `ValueError`.
To be consistent, invalid line names are now silently ignored.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251009130516.3729433-7-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Previously, a check was performed to prevent requests that included
duplicative lines.
While this provided quick feedback on erroneous requests, it penalized
callers that had a good config due to the over head of iterating the
config multiple times.
Now, duplicate check is performed as the config object is iterated.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251009130516.3729433-5-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Previously, an offset map was maintained to lookup the name used to
request a line so that a list could be generated that reflected the
identifier used to request a given line.
For example, if a config looked like {0: None, ("foo", "bar"): None}, the
LineRequest.lines property would contain [0, "foo", "bar"].
Now, the line identifier is tracked in request order as the config
object is iterated to avoid maintaining an offset map.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251009130516.3729433-4-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Previously, Chip.request_lines and LineRequest.reconfigure_lines
iterated over a config object but did so in subtly different ways.
Create a generator that iterates over a config object and returns line +
settings pairs. Update the aforementioned functions to use the generator
to consolidate and condense code.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251009130516.3729433-2-vfazio@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Commit b4009e2e67 ("tests: gpiosim: provide
gpiosim_bank_set_line_valid()") added support for marking simulated GPIO
lines as valid/invalid using a new attribute of the kernel configfs
interface of the gpio-sim module. In the process it bumped the minimum
kernel version required to use it to v6.17 where this feature first
appeared. The test cases we added later only appear in gpiod-test which
is the test suite for the core C library. However with the kernel
version change in libgpiosim other test suites have also seen their
minimum kernel versions implicitly increase.
Since the libgpiosim library will simply return an error in the event
that the attribute in question doesn't exist when the new function is
called, we can revert the required kernel version to what it was before
and allow just the individual test suites to bump their respective
minimums separately.
Reported-by: Vincent Fazio <vfazio@gmail.com>
Tested-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20251010094951.18927-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The problem that was worked around with the AS_IF() hack turned out to
be caused by not expanding PKG_PROG_PKG_CONFIG() before the first
expansion of PKG_CHECK_MODULES(). Moving it near the top of the file
fixes the problem. This allows us to make the tests section consistent
with the rest of the configure.ac file.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Configure errors in the tests section will make it seem like the problem
is related to the core library. Use the correct error macros we define
earlier.
Fixes: 9e69d7552c ("configure: improve the header and library function checks")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Typically we define these right before they're needed in their
respective sections so be consistent and move the two currently defined
at the top of the file to configure sections for tests and C++ bindings.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The header generated by gdbus-codegen and the library wrapper around it
are not part of the stable API so don't install them.
Fixes: a5ab76da1e ("dbus: add the D-Bus daemon, command-line client and tests")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Example programs using the libgpiod GLib bindings are erroneously
installed under $(prefix)/bin/. Change the bin_PROGRAMS make variable
to noinst_PROGRAMS to fix it.
Fixes: e090088c21 ("bindings: add GLib bindings")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Currently gpiocli does not display the libgpiod API version in the
output of gpiocli --version because it's not linked against libgpiod -
it's only a consumer of the DBus API.
However, with the recent changes to the versioning scheme and the
disassociation of the core C API from the libgpiod package version, it
now makes sense to display the latter so add it.
Acked-by: Erik Wierich <erik@riscstar.com>
Link: https://lore.kernel.org/r/20250903-api-version-detach-v1-7-027ca5928518@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The core C API of libgpiod has become quite stable and unlikely to
change soon. We will still be adding some new features to the included
programs and some of the bindings (notably: Python and Rust) but it
doesn't make sense to bump the C API which hasn't changed, just becuase
we're doing a minor release of the larger package.
Define a separate libgpiod C API version in configure.ac. This will
affect the C, C++ and GLib APIs as the latter two track the C API
closely. Rust and Python bindings already have their own API versions.
Set the API version to v2.2.0 as it hasn't changed in the libgpiod v2.3
release cycle yet.
Acked-by: Erik Wierich <erik@riscstar.com>
Link: https://lore.kernel.org/r/20250903-api-version-detach-v1-2-027ca5928518@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The symbols from gpiodcxx/misc.hpp are correctly exported to users of
gpiod.hpp because it's implicitly pulled in by line-request.hpp but
that's incorrect: line-request.hpp has no need for any of the symbols
from misc.hpp and it should be part of the set of headers included by
the top-level gpiod.hpp. Move it to the correct place.
Acked-by: Erik Wierich <erik@riscstar.com>
Link: https://lore.kernel.org/r/20250903-api-version-detach-v1-1-027ca5928518@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When `chip.request_lines` was modified to allow `Iterable`s instead of
only `tuple`s, the code that checked for duplicate line entries in the
`config` argument was not updated to account for the expanded types.
If the `config` argument had a key that was not a `tuple`, `str`, or
`int`, a `TypeError` would be raised when resolving the line offset.
Refactor the code the resolves IDs to offsets into a separate function
to make the logic a bit clearer and to account for the widened types.
Fixes: 8f62e6c453 ("bindings: python: loosen type requirements in public API")
Closes: https://github.com/brgl/libgpiod/issues/148
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Link: https://lore.kernel.org/r/20250902123905.6491-1-vfazio@gmail.com
[Bartosz: don't pass the only argument by name in the call to
_resolve_config_keys_to_offsets()]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
