| Message ID | 20220720104025.1580222-1-emil.renner.berthing@canonical.com |
|---|---|
| Headers | show |
| Series | [SRU,J] UBUNTU: [Config] Enable CONFIG_GPIO_CDEV_V1 | expand |
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@canonical.com> The correct form for a Launchpad URL is 'note<LP: #1953613>'
On Wed, 20 Jul 2022 at 15:11, Tim Gardner <tim.gardner@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@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. /Emil > ----------- > Tim Gardner > Canonical, Inc
On 20.07.22 15:14, Emil Renner Berthing wrote: > On Wed, 20 Jul 2022 at 15:11, Tim Gardner <tim.gardner@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@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. -Stefan > > /Emil >> ----------- >> Tim Gardner >> Canonical, Inc >
On Thu, 21 Jul 2022 at 09:29, Stefan Bader <stefan.bader@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@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@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 > > >
On 21.07.22 09:40, Emil Renner Berthing wrote: > On Thu, 21 Jul 2022 at 09:29, Stefan Bader <stefan.bader@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@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@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. That is the reason I added the explanation here. I am not sure we are very good at explaining WHY something is done a certain way. ;) Feel free to spread the word. -Stefan > > /Emil > >> -Stefan >> >>> >>> /Emil >>>> ----------- >>>> Tim Gardner >>>> Canonical, Inc >>> >>
On Thu, 21 Jul 2022 at 08:30, Stefan Bader <stefan.bader@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@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@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. > It's a patch in Ubuntu's gnome-terminal https://git.launchpad.net/ubuntu/+source/gnome-terminal/tree/debian/patches/60_add_lp_handler.patch @Emil it would be really nice if you were to submit a patch to normalize all the bug links in kinetic annotations file to be LP: #[0-9]* (doesn't matter what is before LP or after digits) =))))))))))))
On 20.07.22 12: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(-) > 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@canonical.com>