The double-quote was also missing its matching pair.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Hopefully this helps identify the failure early in confiure rather than
late when the tests should be executed.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

The current proposed v2.0 API for libgpiod contains so many changes
since v1.x that the items in TODO have become obsolete. For instance:
we can no longer rethink the bulk line objects because they no longer
exist. Same for C++ weak references - in the new version the objects
will no longer be copyable. Remove the libgpiod v2 items entirely.

Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Both legacy sysfs and new character device API support querying line
state of a GPIO configured as output. But while sysfs /value can
be read for these output GPIOs, gpioget unconditionally muxes the
line as input. To ease migration to the new user API, add a new
--dir-as-is parameter that doesn't force the line to input.

This is especially useful for GPIO controllers that maintain their
last configured output state.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
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>

The default mode (exit) doesn't have a callback so we need to check if
the callback funtion pointer isn't NULL.

Fixes: 9b6e6d26 ("ctxless: drop all context-less interfaces")
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>

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>

Make the AC_INIT() expansion consistent with other macros.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

While not necessary to compile, the PyObject_HEAD macros look more
consistent with the rest of the code if they too have semicolons at the
end of the lines.

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>

If "default_vals" is not provided in the kwds then default_vals are
passed uninitialized to gpiod_line_request_bulk(), so rename the
existing default_vals to vals and introduce a new default_vals that
points to vals, or NULL if no defaults have been passed.

Fixes: 96c524c4 (bindings: implement python bindings)
Reported-by: Pedro Botella <pbotella@gmail.com>
Signed-off-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Remove an unnecessary tab from the mockup class header.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

This fixes the following error with clang 11 with libc++:

 line.cpp:248:39: error: implicit instantiation of undefined template 'std::__1::array<gpiod_line_event, 16>'
         ::std::array<::gpiod_line_event, 16> event_buf;
                                              ^
 /nix/store/vk8ynr4hj2a8w7g1b9m8wknzj39iiv4x-libc++-11.0.1/include/c++/v1/__tuple:219:64: note: template is declared here
 template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;

Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.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>

Reorder the definitions so that they match the order in which they're
declared in the class. This is cosmetic only.

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>

This header is a leftover from previous development. Remove it as nobody
requires it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

The test case for requesting multiple lines exposed by different chips
has never been correct. The request call does indeed fail with EINVAL
but now that we've disallowed adding lines from different chips to
the same bulk object, this happens only because we're using a wrong
constant in the flags field of the request structure.

Remove the entire test as it's no longer required.

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>

Example code for bindings is currently always built if bindings are
enabled. Make it conditional with a new configure switch.

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>

This routine should logically be part of line attributes. Move it out
of the misc line section.

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>