ACK/Cmnt: [SRU][K][J, hwe-5.17, oem-5.17, starfive-5.17, allwinner-5.17][PATCH 0/1] Enable CONFIG_GPIO_CDEV_V1
stefan.bader at canonical.com
Fri Aug 5 08:46:59 UTC 2022
On 20.07.22 12:40, Emil Renner Berthing wrote:
> * The libgpiod2 library and gpiod tools shipped in Jammy don't work.
> * These tools are meant to replace the old sysfs interface and be
> a better and more efficient way to manipulate GPIOs from userspace.
> Unfortunately the latest release is still using v1 of the character
> device kernel API which is not enabled in Ubuntu kernels.
> * This is Kent Gibsons reply on the linux-gpio mailing list:
> On Tue, Jul 12, 2022 at 09:48:45AM +0200, Alexandre Ghiti wrote:
>> Ubuntu kernels do not enable GPIO_CDEV_V1 as it is deprecated, but the
>> libgpiod package that we ship is still based on the latest version
>> 1.6.3 which does not implement the API v2. So I'd like to update
>> libgpiod, do you have any recommendations about what branch/sha1 I
>> should use? Do you plan to make a release that implements the API v2?
> Firstly, libgpiod is Bart's library so he is the authority, but this
> is my understanding...
> TLDR: You should keep GPIO_CDEV_V1 enabled.
> v1 is deprecated from a development perspective, so all new feature
> development will occur on v2, and new applications should target v2.
> Existing apps targetting v1, be that directly or via libgpiod v1.6.3,
> will require GPIO_CDEV_V1 until they migrate to v2.
> The mainline kernel will continue to support v1 while userspace
> libgpiod v2 is in active development, and should reach its first release
> Note that it is NOT a plugin replacement for v1. It has a different API,
> for similar reasons to why we had to switch in the kernel, so apps will
> need to be actively migrated.
> I wouldn't suggest making any effort to package libgpiod v2 until Bart
> makes an official release.
> [Test Plan]
> * Run gpioinfo on a machine with exposed GPIOs and check that it lists
> the GPIOs and doesn't error with
> gpioinfo: error creating line iterator: Invalid argument
> [Where problems could occur]
> * There may be code and scripts that hasn't been tested with a working
> libgpiod2/gpiod tools and uncover latent bugs.
> Emil Renner Berthing (1):
> UBUNTU: [Config] Enable CONFIG_GPIO_CDEV_V1
> debian.master/config/annotations | 4 +++-
> debian.master/config/config.common.ubuntu | 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
Just one thing about the subject annotation of the patches. Ideally target
kernels would be specified using the handle format (jammy:linux for example). I
know this is bulky and a lot to type. So "J" can be used instead of jammy:linux
and j:hwe-5.17 would be clear to mean jammy:linux-hwe-5.17. But "J/hwe-5.17" I
normally read as jammy:linux + jammy:linux-hwe-5.17. Because people started to
omit the release if the kernel name is unique for only one release. In this case
its always the same patch, so unlikely has to be applied 5x. But that will not
always be that clear. So just for future reference try to stick with "/" as
separating completely different sources and ":" to separate series and source.
Acked-by: Stefan Bader <stefan.bader at canonical.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the kernel-team