When linking with internal dependencies that were built with libtool the
most reliable method is to use the libtool archive (.la) files.
When building with slibtool it fails when it doesn't find the -lgpiod
linker flag, but if libgpiod is already installed to the system it will
be built using the system version instead of the newly built libraries.
Link: https://bugs.gentoo.org/913899
Signed-off-by: orbea <orbea@riseup.net>
[Bartosz: fix a typo in tests Makefile]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are no thread-safety guarantees in libgpiod. Let's not reuse the
chip object created in one thread to generate info events in another but
create a second chip for that purpose instead.
Reported-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Erik Schilling <erik.schilling@linaro.org>
Provide a wrapper around gpiod_line_request_get_chip_name() for C++
bindings and update the tests.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
I'm not sure what historical reasons there were to install test programs
if they are built but now I can't see any anymore. Tests can be run from
the build directory and users such as meta-openembedded can install them
and the relevant libraries (libgpiosim) manually into the filesystem as
they don't usually live in ${bindir} anyway. Installing test binaries just
pollutes the filesystem now so stop doing it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
It seems like every release there's some new problem with parsing the
version strings in tests. Let's reduce the strictness of the patterns
to avoid future test failures and accept the following version schemes:
X.Y
X.Y.Z
X.Y-devel
X.Y-rcZ
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The square bracket is in the wrong place which makes the regex not match
version strings of the form: x.y.z. Fix the pattern in core and bindings
tests.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We need to actually trigger a line-info event before making sure the watch
has been disabled.
Fixes: f2245fa32c ("bindings: cxx: tests: add a test case for chip::unwatch_line_info()")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We don't have any test case for chip::unwatch_line_info() so add a simple
one similar to the one we have for the core C library.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Extend line_config to expose a new method - set_output_values() - which
wraps the new C function for setting multiple output values at once.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Implement the copy operator for line_settings. We have a copy() method
for line settings in C API while in C++ it's useful to copy line_settings
returned in an std::map from line_config.get_line_settings().
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@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>
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>
The code is not consistent with regard to following the last element in
enums and struct definitions with a comma. Unless the last element is
guaranteed not to change (e.g. '{ }', or NULL), follow it with a comma
treewide to avoid churn in git when adding new values.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The enum itself should just define direction settings, it's the functions
that use it that should refer to hogging.
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 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>
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>
Together with the removal of line objects, we'll entirely drop the
line bulk concept. In order to avoid having to update tests that will
soon be unneeded when introducing further changes, let's remove line
bulk test cases already.
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>
Using LGPL-2.1 for C++ library code is an issue raised several times on
the linux-gpio mailing list. Programs using C++ libraries often include
significant portions of code generated behind the scenes from C++ headers
(via templates, default implementations etc.).
Section 3 of LGPL-3.0 clarifies the use of code defined in or generated
from C++ headers so this changset proposes to use LGPL-3.0 for all C++
library code in libgpiod.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Kent Gibson <warthog618@gmail.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>
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>
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>
Currently the line object has the power to control the parent chip's
lifetime because it stores a hard reference (in the form of a shared
pointer) to the underlying struct gpiod_chip. This is wrong from the
relationship point-of-view - the chip should control the exposed lines,
not the other way around.
Demote the parent reference to a weak_ptr. Introduce a sub-class that
allows line and line_bulk objects to lock the chip by temporarily
converting this weak_ptr to a full shared_ptr - this way we don't risk
dropping the last reference to the parent chip when the line is calling
the underlying library functions. Chip deleted during that time will
expire right after the concerned line method returns.
This requires an API change - the global find_line() function now
returns a <line, chip> pair so that the caller gets the chance to grab
the chip's reference.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The library now uses v2 of the GPIO uAPI. The new user interface is
scheduled for release as part of linux v5.10. Linux v5.10-rc1 is now
tagged so make v5.10 headers a requirement for the build and update
all tests to check for the correct version.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The freq field of struct gpiod_test_event_thread is actually used as a
period measured in milliseconds, so rename it to period_ms in the struct
and wherever it is used as a function parameter.
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add tests to verify the behaviour of get_values when applied to a bulk
of event lines.
Reported-by: Gerrit Wyen <ml@ionscale.com>
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We try to always resolve symbols from std starting from the global
namespace by using the '::' prefix but there are a couple places where
this was missed. This patch makes the resolution consistent treewide.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cleanup the main .gitignore: remove explicit filenames which are already
implicitly ignored with pattern entries and move all the specific
entries into appropriate sub-directories.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Extend the test coverage of C++ bindings with tests of reading of
multiple line events at once.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Extend test coverage over set_config, set_flags, set_direction_input, and
set_direction_output methods.
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Extend test coverage over the bias flags in requests and the bias setting
returned by line.bias().
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
