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

[Emil Renner Berthing]

On Thu, 21 Jul 2022 at 09:29, Stefan Bader <stefan.bader at canonical.com> wrote:
> On 20.07.22 15:14, Emil Renner Berthing wrote:
> > On Wed, 20 Jul 2022 at 15:11, Tim Gardner <tim.gardner at canonical.com> wrote:
> >> On 7/20/22 04:40, Emil Renner Berthing wrote:
> >>> [Impact]
> >>>
> >>>    * 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:
> >>>> Hi,
> >>>>
> >>>> 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
> >>> transitions.
> >>>
> >>> libgpiod v2 is in active development, and should reach its first release
> >>> shortly.
> >>> 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.
> >>>
> >>> Cheers,
> >>> Kent.
> >>>
> >>> [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(-)
> >>>
> >> Acked-by: Tim Gardner <tim.gardner at canonical.com>
> >>
> >> The correct form for a Launchpad URL is 'note<LP: #1953613>'
> >
> > Ah, I see, thanks. Yeah, the annotations file in kinetic:linux has a
> > lot of different variations, so I just went with one of the most
> > common ones.
>
> The reasoning here is that with some shell pattern matching magic (not quite
> sure this is a default or something I installed over time) the form "LP: #123"
> becomes a link which can be clicked.

That makes sense, but right now only 1/136 entries in kinetic:linux
use that form,
3/136 if you allow trailing free text.

/Emil

> -Stefan
>
> >
> > /Emil
> >> -----------
> >> Tim Gardner
> >> Canonical, Inc
> >
>