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

[Andy Shevchenko]

On Mon, Aug 8, 2022 at 4:57 PM Andy Shevchenko
<andy.shevchenko at gmail.com> wrote:
> On Sun, Aug 7, 2022 at 4:57 PM Ian Pilcher <arequipeno at 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