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

[Ian Pilcher <arequipeno@gmail.com>]

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
========================================================================