A problem with gpios on my sunxi board.

A problem with gpios on my sunxi board.

[Gasai Maple]

I posted a question on stackoverflow, it's basically about me having
problems operating gpio with libgpiod, and a user advised me to drop a
message, the link is here
https://stackoverflow.com/questions/70863283/libgpiod-tests-fails-on-pcduino3-nano

Re: A problem with gpios on my sunxi board.

[Kent Gibson]

On Fri, Jan 28, 2022 at 10:12:13PM +0800, Gasai Maple wrote:
> I posted a question on stackoverflow, it's basically about me having
> problems operating gpio with libgpiod, and a user advised me to drop a
> message, the link is here
> https://stackoverflow.com/questions/70863283/libgpiod-tests-fails-on-pcduino3-nano

It would be helpful to restate your question rather than providing the
link.  But anyway...

My best guess is that your kernel is built with only v2 of the GPIO CDEV ABI.
libgpiod support for v2 is a WIP, and 1.6.3 only supports ABI v1.
The CHIP_INFO ioctl is common to both, so will still work.
But all the line request ioctls changed so they wont.
So libgpiod is probably making ioctl calls that your kernel doesn't
support.

For compatibility with libgpiod v1.6.3, ensure your kernel is built with
these options:

CONFIG_GPIO_CDEV=y
CONFIG_GPIO_CDEV_V1=y

And the libgpiod tests require that gpio-mockup is available as a loadable
module, so

CONFIG_GPIO_MOCKUP=m

If building a new kernel isn't an option for you then you might want to
try the development branch of libgpiod[1].
Or you could try my Go[2] or Rust[3] libraries that both support both
versions of the ABI and provide tools equivalent to libgpiod.

If you still have issues, try using strace to display the ioctl calls and
we can debug that.

Cheers,
Kent.

[1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/log/?h=next/libgpiod-2.0
[2] https://github.com/warthog618/gpiod
[3] https://github.com/warthog618/gpiod-rs

Re: A problem with gpios on my sunxi board.

[Kent Gibson]

On Mon, Jan 31, 2022 at 08:59:24AM +0800, Kent Gibson wrote:
> On Fri, Jan 28, 2022 at 10:12:13PM +0800, Gasai Maple wrote:
> > I posted a question on stackoverflow, it's basically about me having
> > problems operating gpio with libgpiod, and a user advised me to drop a
> > message, the link is here
> > https://stackoverflow.com/questions/70863283/libgpiod-tests-fails-on-pcduino3-nano
> 
> It would be helpful to restate your question rather than providing the
> link.  But anyway...
> 
> My best guess is that your kernel is built with only v2 of the GPIO CDEV ABI.
> libgpiod support for v2 is a WIP, and 1.6.3 only supports ABI v1.
> The CHIP_INFO ioctl is common to both, so will still work.
> But all the line request ioctls changed so they wont.
> So libgpiod is probably making ioctl calls that your kernel doesn't
> support.
> 

On re-reading your issue I realise it is the LINE_INFO ioctl that is
working for you, not CHIP_INFO.  That indicates ABI v1 is present in
your kernel, so the above is wrong.

That brings me back to using strace to see what is happening in the
ioctl calls.

And what does gpioget return?

Cheers,
Kent.

Re: A problem with gpios on my sunxi board.

[Andy Shevchenko]

On Mon, Jan 31, 2022 at 08:59:24AM +0800, Kent Gibson wrote:
> On Fri, Jan 28, 2022 at 10:12:13PM +0800, Gasai Maple wrote:
> > I posted a question on stackoverflow, it's basically about me having
> > problems operating gpio with libgpiod, and a user advised me to drop a
> > message, the link is here
> > https://stackoverflow.com/questions/70863283/libgpiod-tests-fails-on-pcduino3-nano
> 
> It would be helpful to restate your question rather than providing the
> link.  But anyway...
> 
> My best guess is that your kernel is built with only v2 of the GPIO CDEV ABI.
> libgpiod support for v2 is a WIP, and 1.6.3 only supports ABI v1.
> The CHIP_INFO ioctl is common to both, so will still work.
> But all the line request ioctls changed so they wont.
> So libgpiod is probably making ioctl calls that your kernel doesn't
> support.

If this the case, can we add some warning to libgpiod tools to tell user that
the results may be way wrong because of that?

> For compatibility with libgpiod v1.6.3, ensure your kernel is built with
> these options:
> 
> CONFIG_GPIO_CDEV=y
> CONFIG_GPIO_CDEV_V1=y
> 
> And the libgpiod tests require that gpio-mockup is available as a loadable
> module, so
> 
> CONFIG_GPIO_MOCKUP=m
> 
> If building a new kernel isn't an option for you then you might want to
> try the development branch of libgpiod[1].
> Or you could try my Go[2] or Rust[3] libraries that both support both
> versions of the ABI and provide tools equivalent to libgpiod.
> 
> If you still have issues, try using strace to display the ioctl calls and
> we can debug that.
> 
> Cheers,
> Kent.
> 
> [1] https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/log/?h=next/libgpiod-2.0
> [2] https://github.com/warthog618/gpiod
> [3] https://github.com/warthog618/gpiod-rs

-- 
With Best Regards,
Andy Shevchenko

Re: A problem with gpios on my sunxi board.

[Kent Gibson]

On Mon, Jan 31, 2022 at 01:26:36PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 31, 2022 at 08:59:24AM +0800, Kent Gibson wrote:
> > On Fri, Jan 28, 2022 at 10:12:13PM +0800, Gasai Maple wrote:
> > > I posted a question on stackoverflow, it's basically about me having
> > > problems operating gpio with libgpiod, and a user advised me to drop a
> > > message, the link is here
> > > https://stackoverflow.com/questions/70863283/libgpiod-tests-fails-on-pcduino3-nano
> > 
> > It would be helpful to restate your question rather than providing the
> > link.  But anyway...
> > 
> > My best guess is that your kernel is built with only v2 of the GPIO CDEV ABI.
> > libgpiod support for v2 is a WIP, and 1.6.3 only supports ABI v1.
> > The CHIP_INFO ioctl is common to both, so will still work.
> > But all the line request ioctls changed so they wont.
> > So libgpiod is probably making ioctl calls that your kernel doesn't
> > support.
> 
> If this the case, can we add some warning to libgpiod tools to tell user that
> the results may be way wrong because of that?
> 

Turns out not to be the case here, but the results wont be "way wrong"
- the ioctl call will just fail as it doesn't exist in the kernel.
Unfortunately that returns a generic EINVAL that can't be distinquished
from other causes of the same error.

Cheers,
Kent.