- don't decref objects on PyList_SetItem() failure
- check for errors after PyIter_Next() in request_get_values() and
set_output_values()
- release the GIL in chip_get_info()
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
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>
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>
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>
Bump the errno dependency for gpiosim-sys and libgpiod crates to the
most recent version which is a minor update from the one we have now.
However: let cargo select it automatically by not specifying the bugfix
version. We need to be stricter than just selecting the major version
alone because crates with major versions starting with 0 can introduce
breaking changes in minor releases. No code changes required.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Erik Wierich <erik@riscstar.com>
Link: https://lore.kernel.org/r/20250828-rust-1-0-0-release-v3-5-0f9c6c1c4808@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
These are block attributes, but the newline in between suggests that
they are for the whole module.
Fixes clippy warning:
warning: empty line after outer attribute
--> libgpiod-sys/src/lib.rs:6:1
|
6 | / #[cfg_attr(test, allow(deref_nullptr, non_snake_case))]
7 | |
| |_^
8 | mod bindings_raw {
| ---------------- the attribute applies to this module
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#empty_line_after_outer_attr
= note: `#[warn(clippy::empty_line_after_outer_attr)]` on by default
= help: if the empty line is unintentional, remove it
help: if the attribute should apply to the crate use an inner attribute
|
5 ~ #![allow(non_camel_case_types, non_upper_case_globals)]
6 ~ #![cfg_attr(test, allow(deref_nullptr, non_snake_case))]
|
Signed-off-by: Erik Wierich <erik@riscstar.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20250721-rust-clippy-v1-1-2ac0198b2ea6@riscstar.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
