Add support for GPIO line names via libgpiod#4
Open
mhei wants to merge 16 commits into
Open
Conversation
This is not required anymore. Quoting glibc 2.30 NEWS:
> * The functions clock_gettime, clock_getres, clock_settime,
> clock_getcpuclockid, clock_nanosleep were removed from the librt library
> for new applications (on architectures which had them). Instead, the
> definitions in libc will be used automatically, which have been available
> since glibc 2.17.
When building in a BitBake devshell as shared library and inspecting
the resulting .so file with readelf reveals that librt.so is never
linked to:
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x0000000000000001 (NEEDED) Shared library: [ld-linux-aarch64.so.1]
0x000000000000000e (SONAME) Library soname: [liblibnfc_nci.so]
This will also fix
do_package_qa: QA Issue: File /usr/lib/cmake/libnfc-nci/libnfc-nci-targets.cmake in package libnfc-nci-dev contains reference to TMPDIR [buildpaths]
in yocto builds since it contained a full path to librt.so.
Signed-off-by: Tafil Avdyli <tafil@tafhub.de>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Invalid file descriptor is -1, values >= must be considered valid. While at, get rid of the Close method is derived class since the functionality is the same for all derived classes. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This uses a proprietary ioctl which will not work with default I2C or SPI interface devices on Linux. I guess this is left-over copy&paste garbage. Remove it since there seems no user of this methods. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Destination buffer must not overflow, so check size of buffer and string length. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
We need to pass the size of the target variable, not the size of the pointer to it. This is important on platforms where sizeof(pointer) != sizeof(int) Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
lategoodbye
suggested changes
Apr 29, 2026
This should make it more clear, that mixing is undefined behavior. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
We can re-use kernel's maximum GPIO line name length here instead of a random hard-coded size. While at, improve the debug messages to support users when using the new feature. Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
lategoodbye
approved these changes
May 4, 2026
|
@cburandt Friendly ping ;-) |
Author
|
Any comments, positive or negative, are welcome, as is regression testing on existing platforms. |
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
Author
|
I had problems to cross-compile the library and the PN7160TokenProvider using Yocto kirkstone, so I added a commit here to create a shared library. This requires also a small change in the CMake file of PN7160TokenProvider, you can find it here as example: https://github.com/chargebyte/everest-core/commits/feature/pn7160-as-shared-lib/ |
Signed-off-by: Michael Heimpold <michael.heimpold@chargebyte.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The good old sysfs based user-space interface with GPIO numbers is obsolete since several years.
This PR add support for an alternative approach: instead of plain integers, user can configure the required GPIO lines using a GPIO line name as usually defined in the Device Tree for the board. For this, this PR relys on
libgpiod. Support for using libgpiod can be switched on at compile time, to keep backwards compatiblity, it is disabled by default.The new dependency is not pulled in automatically but is expected to be provided by the environment.
The tested libgpiod version is v2.0.1 - since this is currently the version that we (chargebyte) bundle in our kirkstone builds on our targets.
Even if the library is compiled with libgpiod support, then it is still possible to use integer numbers and the older sysfs interface.
Sidenote 1: I pulled in the commit from #3 - just wanted to have it included when testing. I can remove it once there is a decision/feedback in that PR.
Sidenote 2: I tested only on our Charge SOM platform so far and fixed a 64-bit issue from an older commit in this branch.
I'm unsure regarding the
ADDITIONAL_CONTENTstuff in the packaging file - this is untested and I hope someone with more expertise can comment on it.