We keep a single instance of a struct gpiod_line_settings object shared
by all offsets using it. Everytime gpiod_line_config_add_line_settings()
is called, we append it to the per-line-config linked list and reference
it from every per-offset structure.
However we don't keep track of the offsets referencing a settings object
and don't remove it when there are no more offsets associated with it -
we only do it when the user frees or resets the line-config object.
Extend the settings_node structure: make it a doubly-linked list -
allowing to easily remove individual nodes - and add a reference count.
Keep track of how many offsets reference a line-settings object and when
that reference count drops to 0, remove it.
Fixes: b7ba732e6a ("treewide: libgpiod v2 implementation")
Closes: https://github.com/brgl/libgpiod/issues/130
Link: https://lore.kernel.org/r/20250424-line_config_mem_use-v1-1-fa0abdcf0cdf@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The Makefile in lib/ is missing a space in LDFLAGS assignment. Add it.
This is not a functional change, just coding style.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
If the kernel GPIO driver (erroneously) returns a positive value from one
of its callbacks, it may end up being propagated to user space as
a positive value returned by the call to ioctl(). Let's treat all
non-zero values as errors as GPIO uAPI ioctl()s are not expected to ever
return positive values.
To that end let's create a wrapper around the libc's ioctl() that checks
the return value and sets errno to EBADE (Invalid exchange) if it's
greater than 0.
This should be addressed in the kernel but will remain a problem on older
or unpatched versions so we need to sanitize it in user-space too.
Reported-by: José Guilherme de Castro Rodrigues <joseguilhermebh@hotmail.com>
Fixes: b7ba732e6a ("treewide: libgpiod v2 implementation")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Kent Gibson <warthog618@gmail.com>
We try to drop potentially set output flags from line config if edge
detection is enabled but we use the library enum instead of the one from
the uAPI. In any case, we should actually loudly complain if user tries
to use the output mode with edge-detection (like we do currently) so just
remove offending lines entirely.
Reported-by: Anne Bezemer <j.a.bezemer@opensourcepartners.nl>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Kent Gibson <warthog618@gmail.com>
Reviewed-by: Anne Bezemer <j.a.bezemer@opensourcepartners.nl>
While we can get the list of requested offsets from a line-request object,
this information lacks context if we don't provide any data about the GPIO
chip the request was made on. Add a helper allowing users to get the name
of the parent chip.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add an assert() for the line config structure and check the rest of the
arguments for invalid values.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
After discussing this a while back we removed the call to fcntl() that
would make the request file descriptor non-blocking so that a call to
gpiod_line_request_read_edge_events() would block if no events are
pending. We agreed that the same behavior should apply to info events and
made the docs state that. Unfortunately we still pass the O_NONBLOCK flag
to open() making read() called on the chip file descriptor return
immediately if no info events are pending. Fix it by removing this flag.
Fixes: b7ba732e6a ("treewide: libgpiod v2 implementation")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We check the output values for invalid ones in
gpiod_line_settings_set_output_value() but in
gpiod_line_config_set_output_values() we just accept all indiscriminately.
Factor out the common checking code into a helper function, use it in both
functions and add a relevant test case.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Currently if user wants to use the same settings for a set of requested
lines with the exception of the output value - they need to go through
hoops by updating the line settings object and adding it one by one to
the line config. Provide a helper function that allows to set a global
list of output values that override the settings. For details on the
interface: see documentation in this commit.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We have two functions in the C API that allow users to retrieve a list
of offsets from objects: gpiod_line_request_get_offsets() and
gpiod_line_config_get_offsets(). Even though they serve pretty much the
same purpose, they have different signatures and one of them also
requires the user to free the memory allocated within the libgpiod
library with a non-libgpiod free() function.
Unify them: make them take the array in which to store offsets and the
size of this array. Make them return the number of offsets actually
stored in the array and make them impossible to fail. Change their names
to be more descriptive and in the case of line_config: add a new function
that allows users to get the number of configured offsets.
Update the entire tree to use the new interfaces.
For rust bindings: also unify the line config interface to return a map
of line settings like C++ bindings do instead of having a function to
get settings by offset. A map returned from a single call is easier to
iterate over with a for loop than using an integer and calling the
previous line_settings() method.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Use the most common and readable convention for listing source files
in Makefiles wherever it's not consistent yet.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Currently we almost never check the validity of pointers passed to the
core C API routines. While we cannot know if a non-NULL pointer points
to an actual object, we can at least verify that it is not NULL before
dereferencing it.
Conceptually we can think of two categories of pointers in libgpiod:
First, there are the objects we manipulate using the API. These are
normally the first arguments in any given method and they are only
instantiated inside the library and never dereferenced by the user.
They should always be valid, so passing a NULL pointer here should
always lead to a crash. Currently it will take the form of a segfault
at the moment of dereference but with this change, we make the user
program abort() with the stack trace pointing right at the offender.
The second category would be pointers to objects that are logically
parameters of methods i.e. not their first argument. Example is:
gpiod_chip_request_lines(chip, req_cfg, line_cfg) (whose logical OOP
version would be: chip->request_lines(req_cfg, line_cfg)). Here we
accept a NULL req_cfg but we'll segfault on a NULL line_cfg. For
consistency: don't crash here but instead return -1 and set errno
to EINVAL. Same everywhere else.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Unless we dereference it before passing it to free(), we don't need to
care whether the pointer is NULL - free() can handle it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Rename the static function that uses the word 'chip' twice in its name.
Just remove the prefix as we don't export this symbol.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Instead of telling the user what type this function returns (they can
check it by looking at the prototype), tell them what the return value
actually represents.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
While we use it for edge event timestamps exclusively at the moment,
the actual enum names shouldn't limit its application and simply just
refer to existing clock types known by the GPIO uAPI. The relevant
functions are still called set/get_event_clock() as it's in line with
their functionality.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
The read_edge_event() family of functions should actually be called
read_edge_events() as they universally allow to read more than one
event. We're converting wait_edge_event() too for consistency.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Use linux kernel's .clang-format file to automatically improve the coding
style of libgpiod's C code base. We don't import the file into the
repository as it's not perfect and certain converted fragments were
rolled back because they looked better before the conversion.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use enum types explicitly across the entire C API. Modern compilers can
catch some bugs with enums and it also helps IDEs and general readability.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
[Viresh: make rust bindings work with negative enum values]
Co-authored-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
This commit is the result of a squash of all the commits created during
the development of libgpiod v2. This is done to preserve bisectability
of the git tree. It contains significant re-writes of the core C library
as well as C++ and python bindings. The tools have been adjusted to work
with the new API but have not undergone significant changes yet.
This commit contains the bulk of the work on libgpiod v2 but the
development continues with more changes planned.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
[Ben: fix format specifier for uint64_t]
Signed-off-by: Ben Hutchings <ben.hutchings@mind.be>
[Viresh: Fix ioctl number for gpiod_line_request_reconfigure_lines()]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[Kent: bug fixes, improvements, better pointer contracts, type strictness]
Signed-off-by: Kent Gibson <warthog618@gmail.com>
bulk->lines is an array of pointers, so it doesn't matter which pointer
type we specify to sizeof(). As it's a struct gpiod_line *, it would
make sense to use that.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In v2 API all getters will be called using the following pattern:
gpiod_<object>_get_<what>
Apply this to already existing getters for gpiod_chip.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Currently libgpiod requires that the GPIO chip character device be named
'gpiochip%u' in devfs. However it's a perfectly valid use-case to have
the device file renamed by udev (or equivalent) to anything else.
Modify gpiod_is_gpiochip_device() to check the major and minor device
numbers first and then ensure that the device in question is associated
with the GPIO subsystem. No longer check the name.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
GPIOD_API is unneccesarily polluting the user-facing headers. There's no
advantage to having it in public files. Let's make them internal to the
library. Upcoming modifications will also make GPIOD_BIT() redundant so
we'll be able to remove all macros unrelated to the main functionality
from gpiod.h.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This removes any trace of line updating from the API (C, C++ and Python).
The line objects will soon disappear entirely so in order to make the
gradual transition to the new data model easier, remove
gpiod_line_update().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This removes another two functions from the C API as well as their
bindings that don't make much sense (since the user should know if
they have requested the line or not).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The preferred approach in low-level system libraries is to make all
exposed data structures opaque and use reference counting for their
memory management. This changes the chip objects to only close their
underlying character device and release all resources once the reference
count goes down to 0. We remove the gpiod_chip_close() function and
replace it with gpiod_chip_ref() and gpiod_chip_unref().
Other objects in the API will either be removed or are not opaque yet
and will be reworked later.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We're preparing to entirely remove the line objects from the API and
split their functionality between two new objects: line_info and
line_request. The lookup functions must be limited in the process.
This reworks all the find_line methods to: a) always assume that names
looked for are unique within a single chip (because while it's
technically possible for GPIO line names to be non-unique, it doesn't
make sense to look for two lines named the same) and b) return the
hardware offset within the chip instead of the line object.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
LGPL-2.1 is a license meant for shared libraries. Because I didn't know
any better I used it for all files in the repository, including programs
linking against libgpiod. The standard approach for many similar projects
is to use LGPL for library code and GPL for programs (and also Makefiles
and other files containing code or configuration).
Relicense all programs, tests, makefiles and autotools files under
GPL-2.0 or later.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Kent Gibson <warthog618@gmail.com>
In order to make the licensing situation of libgpiod clear and enable
easy reusing of the code, let's make all the files in the repository
compliant with the REUSE v3.0 specification.
In order to achieve that:
- put all used licenses into a separate LICENSES/ directory
- add SPDX license identifiers to all files that were missing them with
regular text files being licensed under CC-BY-SA-4.0, while files
containing code and configuration are licensed under GPL-2.0-or-later
- replace custom copyright texts with SPDX-FileCopyrightText
- update the gpio.h kernel uAPI header with the upstream version where
the SDPX license identifier was fixed to use 'GPL-2.0-only' variant
instead of the deprecated 'GPL-2.0'
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Kent Gibson <warthog618@gmail.com>
In order to avoid any problems with symbols missing from the host linux
kernel headers (for example: if current version of libgpiod supports
features that were added recently to the kernel but the host headers are
outdated and don't export required symbols) let's add the uapi header to
the repository and include it instead of the one in /usr/include/linux.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Open-source and open-drain drive settings are mutually exclusive just like
the bias settings. Make them into an enum so that becomes clear.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
When we're reading the current bias setting of a line, it is already
disabled so the flag should be named as such. While BIAS_DISABLE would
technically be fine when modifying the setting, let's rename it to
BIAS_DISABLED too for consistency.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
When inspecting the current bias setting of a GPIO line, the AS_IS name
of one of the possible values really means that the kernel GPIO subsystem
can't determine the bias setting because it didn't set it itself (e.g.
the hardware may have internally initialized pull-up or pull-down
resistors). In this case it's better to change the name to BIAS_UNKNOWN
to reflect that.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Unlike line direction - where input and output modes are equal, no signal
inversion (active-high) is the natural state of the line while active-low
is less likely. Let's drop the ACTIVE_STATE enum treewide and provide a
boolean property for lines - is_active_low() - to reflect that fact. This
function returning false means the line is "active-high".
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Helper wrappers around gpiod_chip_open() shouldn't really be part of
the core, low-level library. They assume that devtmpfs is mounted at
/dev and that GPIO chips follow the gpiochipX naming convention.
This changeset removes all variants of gpiod_chip_open() other than
the one taking the path as argument. We're doing this treewide so
C++ and Python bindings lose the 'how' argument that currently allows
to change the way the chips are opened by the chip's constructors or
the open() method in C++.
The gpio-tools programs still support opening chips by number, name
and path but they implement this functionality locally rather than
using the library code.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Chip iterators require the user to have permission to access all GPIO
chips. They also don't take into account symbolic links. In general
they're badly designed so remove them treewide in favor of scanning /dev
manually using the provided gpiod_is_gpiochip_device() helper.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
GPIO line names are not unique and the library has been incorrectly
making such assumption in v1.x series. We've already dropped interfaces
that would be too complicated to maintain when taking this into account.
Let's now rework the remaming API. This introduces a new function to the
C API: gpiod_chip_find_line_unique() which assumes that the line name is
unique and signals an error if it's not. The previous
gpiod_chip_find_line() function now returns a bulk object containing all
matching lines.
Python and C++ bindings are updated: their find_line() functions return
bulk objects (or an ::std::vector> too now and they take an additional
argument specifying whether we're looking for a unique line or not.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
GPIO line names are not unique. Looking up multiple lines by names would
require us to return a list of matching lines for every name. We're
simplifying the library API so drop this interface treewide.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Global line lookup doesn't really work correctly because GPIO line names
are not unique. We'd have to return a list of matching lines. Also: not
all chips may be accessible by user in which case the chip iterator will
fail. We'll soon be removing chip iterators entirely so for now drop the
global line lookup and let users iterate over chips themselves.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We're dropping all interfaces for global line lookup and accessing. Lines
should be always accessed via their owning chip object.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This helper was supposed to be used together with global line lookup
which will soon be removed so drop this one too.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Chip labels are not unique - opening chips by label may lead to errors
or to ignoring chips with duplicate labels. Users can easily implement
chip lookup by label themselves so remove this part from the core library
and all bindings.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Hand-crafted iterators don't make much sense in C and impose an
additional layer of memory allocation and resource releasing. Remove
the line iterators from the core C library.
We're leaving the iterators where they make sense: in C++ and Python
bindings but we convert them to using other means of keeping track of
lines.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The limit of 64 lines max per bulk object is wrong. We may want to
retrieve all lines from a chip exporting more than 64. We'll be reducing
the role of bulk objects soon so drop this limit now.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
