gpiod_get() - How to get GPIO from chip & offset?

gpiod_get() - How to get GPIO from chip & offset?

[Ian Pilcher]

I am trying to figure out how to use gpiod_get(), or one of its
variants, to get the descriptor (struct gpio_desc *) for a specific
GPIO.  Getting a reference to the GPIO chip (struct gpio_chip *) is
straightforward, and it provides a pointer to the device (.parent), but
I absolutely cannot figure out what I am supposed to pass as the
*con_id* argument.

I know the offset of the GPIO on the chip, but I can't figure out how to
use that.

Ultimately, my goal is to set the direction of the GPIO from within a
"board setup" module.


BACKGROUND

I maintain an out-of-tree "board" module[1] that sets up the GPIOs and
LEDs on my Thecus NAS.  I am in the process of upgrading the OS on the
NAS, which will require me to change the user-space daemon from the old
sysfs GPIO interface to the new (non-ancient?) gpiod interface.

One significant difference between the sysfs and gpiod interfaces, is
that the new interface does not seem to provide an easy way to set a
GPIO's direction (input/output) from a shell script[2].  Thus, I would
like the board module to do that, along with the other setup.

[1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c

[2] It may be possible to change a GPIO's direction from user space with
     the C API, but doing it in the kernel module, which does all of the
     other hardware configuration, seems like the most appropriate way.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

Re: gpiod_get() - How to get GPIO from chip & offset?

[Kent Gibson]

On Sun, Aug 07, 2022 at 09:55:32AM -0500, Ian Pilcher wrote:
> I am trying to figure out how to use gpiod_get(), or one of its
> variants, to get the descriptor (struct gpio_desc *) for a specific
> GPIO.  Getting a reference to the GPIO chip (struct gpio_chip *) is
> straightforward, and it provides a pointer to the device (.parent), but
> I absolutely cannot figure out what I am supposed to pass as the
> *con_id* argument.
> 
> I know the offset of the GPIO on the chip, but I can't figure out how to
> use that.
> 
> Ultimately, my goal is to set the direction of the GPIO from within a
> "board setup" module.
> 
> 
> BACKGROUND
> 
> I maintain an out-of-tree "board" module[1] that sets up the GPIOs and
> LEDs on my Thecus NAS.  I am in the process of upgrading the OS on the
> NAS, which will require me to change the user-space daemon from the old
> sysfs GPIO interface to the new (non-ancient?) gpiod interface.
> 

So the daemon should use libgpiod to control the line where it used to
use sysfs.

> One significant difference between the sysfs and gpiod interfaces, is
> that the new interface does not seem to provide an easy way to set a
> GPIO's direction (input/output) from a shell script[2].  Thus, I would
> like the board module to do that, along with the other setup.
> 
> [1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
> 
> [2] It may be possible to change a GPIO's direction from user space with
>     the C API, but doing it in the kernel module, which does all of the
>     other hardware configuration, seems like the most appropriate way.
> 

Understand that configuration applied to a line, be it by the module or
from userspace, only remains valid while the line is held.
Once you free the line the state of the line may revert to its default
state.  sysfs effectively holds the line indefinitely, which is one of
its problems.

So the line should be configured by whatever will be controlling it. If
that is the module then the module.  If it is the userspace daemon then
the userspace daemon.

If the issue is changing the daemon from using sysfs to cdev then there
should be no changes required to the module.

The gpioset and gpioget tools provided by libgpiod change the direction
of the line from shell, but that is not relevant to your case as you
should be using the C API provided by libgpiod.

Cheers,
Kent.

Re: gpiod_get() - How to get GPIO from chip & offset?

[Andy Shevchenko]

On Sun, Aug 7, 2022 at 4:57 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> I am trying to figure out how to use gpiod_get(), or one of its
> variants, to get the descriptor (struct gpio_desc *) for a specific
> GPIO.  Getting a reference to the GPIO chip (struct gpio_chip *) is
> straightforward, and it provides a pointer to the device (.parent), but
> I absolutely cannot figure out what I am supposed to pass as the
> *con_id* argument.

Ah, looking into your driver code [1] I think you need to a) switch to
use existing GPIO driver, which is gpio-ich.c in your case and b) use
GPIO lookup tables, you may look at Simatech latest development on how
to achieve that. It uses some Intel chips and LEDs that are connected
to GPIOs.

> I know the offset of the GPIO on the chip, but I can't figure out how to
> use that.

And you don't need to use GPIO offset, whatever it means. What you
need is to have a relative number of GPIO to the chip, so GPIO chip +
relative offset will uniquely give you the line.

> Ultimately, my goal is to set the direction of the GPIO from within a
> "board setup" module.
>
>
> BACKGROUND
>
> I maintain an out-of-tree "board" module[1] that sets up the GPIOs and
> LEDs on my Thecus NAS.  I am in the process of upgrading the OS on the
> NAS, which will require me to change the user-space daemon from the old
> sysfs GPIO interface to the new (non-ancient?) gpiod interface.
>
> One significant difference between the sysfs and gpiod interfaces, is
> that the new interface does not seem to provide an easy way to set a
> GPIO's direction (input/output) from a shell script[2].  Thus, I would
> like the board module to do that, along with the other setup.
>
> [1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c

Why not try to upstream this?

-- 
With Best Regards,
Andy Shevchenko

Re: gpiod_get() - How to get GPIO from chip & offset?

[Andy Shevchenko]

On Mon, Aug 8, 2022 at 4:57 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Sun, Aug 7, 2022 at 4:57 PM Ian Pilcher <arequipeno@gmail.com> wrote:
> >
> > I am trying to figure out how to use gpiod_get(), or one of its
> > variants, to get the descriptor (struct gpio_desc *) for a specific
> > GPIO.  Getting a reference to the GPIO chip (struct gpio_chip *) is
> > straightforward, and it provides a pointer to the device (.parent), but
> > I absolutely cannot figure out what I am supposed to pass as the
> > *con_id* argument.
>
> Ah, looking into your driver code [1] I think you need to a) switch to
> use existing GPIO driver, which is gpio-ich.c in your case and b) use
> GPIO lookup tables, you may look at Simatech latest development on how
> to achieve that. It uses some Intel chips and LEDs that are connected
> to GPIOs.

Same for your I2C GPIO expander, why do you not use the kernel driver for it?!

> > I know the offset of the GPIO on the chip, but I can't figure out how to
> > use that.
>
> And you don't need to use GPIO offset, whatever it means. What you
> need is to have a relative number of GPIO to the chip, so GPIO chip +
> relative offset will uniquely give you the line.
>
> > Ultimately, my goal is to set the direction of the GPIO from within a
> > "board setup" module.
> >
> >
> > BACKGROUND
> >
> > I maintain an out-of-tree "board" module[1] that sets up the GPIOs and
> > LEDs on my Thecus NAS.  I am in the process of upgrading the OS on the
> > NAS, which will require me to change the user-space daemon from the old
> > sysfs GPIO interface to the new (non-ancient?) gpiod interface.
> >
> > One significant difference between the sysfs and gpiod interfaces, is
> > that the new interface does not seem to provide an easy way to set a
> > GPIO's direction (input/output) from a shell script[2].  Thus, I would
> > like the board module to do that, along with the other setup.
> >
> > [1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
>
> Why not try to upstream this?

With the above additional remark I think you will learn a lot about
Linux kernel programming if you try to upstream, even unsuccessfully
(which I don't believe can happen if you listen to maintainers, e.g.
PDx86 subsystem maintainer where your code belongs to).

-- 
With Best Regards,
Andy Shevchenko

Re: gpiod_get() - How to get GPIO from chip & offset?

[Ian Pilcher]

On 8/8/22 10:00, Andy Shevchenko wrote:
> On Mon, Aug 8, 2022 at 4:57 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Sun, Aug 7, 2022 at 4:57 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>> Ah, looking into your driver code [1] I think you need to a) switch to
>> use existing GPIO driver, which is gpio-ich.c in your case and b) use
>> GPIO lookup tables, you may look at Simatech latest development on how
>> to achieve that. It uses some Intel chips and LEDs that are connected
>> to GPIOs.
> 
> Same for your I2C GPIO expander, why do you not use the kernel driver for it?!

That "board" module is ancient.  I originally wrote it when I installed
CentOS 6 (kernel 2.6) on my NAS.  Since then, I've only ever touched it
when something breaks - either for me or for one of a very small number
of other users.  In fact, I was running CentOS 7 on the NAS until last
week, when I decided it was finally time to move to a more modern OS.

>>> I know the offset of the GPIO on the chip, but I can't figure out how to
>>> use that.
>>
>> And you don't need to use GPIO offset, whatever it means. What you
>> need is to have a relative number of GPIO to the chip, so GPIO chip +
>> relative offset will uniquely give you the line.

I was using "offset" to refer to the relative number of the GPIO on the
chip, so we're talking about the same thing here.

>>> Ultimately, my goal is to set the direction of the GPIO from within a
>>> "board setup" module.

This turned out to be a bad idea.  It turns out to be easy to set the
GPIO direction from user space, so I'm doing it that way, regardless of
how elegant or inelegant it is.

>>> [1] https://github.com/ipilcher/n5550/blob/master/modules/n5550_board.c
>>
>> Why not try to upstream this?

Mainly because it's a super-niche use case that's never seemed worth the
trouble, as the vast majority of people just run the Thecus-provided OS.

> With the above additional remark I think you will learn a lot about
> Linux kernel programming if you try to upstream, even unsuccessfully

I'm sure that I would, possibly more than I want to.  :-)  (My goal is
not to become a kernel developer; I simply want the blinky lights on my
NAS to work.)

> (which I don't believe can happen if you listen to maintainers, e.g.
> PDx86 subsystem maintainer where your code belongs to).

Well, my own experience doesn't necessarily bear that out (see my
efforts to contribute the block device LED trigger), but point taken.

Again, thanks for the response!

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================