>> The device tree can configure labels for each line that one
can read/compare using GPIO_GET_LINEINFO_IOCTL. If that is not the case, one would have to
either read the docs (often the schematic) or do trial'n'error.
> Okay, so I'm guessing we might need to expose this in the future somehow.
I have these in my dirty tree now:
struct l_gpio_line *l_gpio_chip_get_line(struct l_gpio_chip *gpio_chip,
struct l_gpio_line *l_gpio_chip_find_line(struct l_gpio_chip *gpio_chip,
const char *line_label);
struct l_gpio_line *l_gpio_find_line(const char *line_label);
struct l_gpio_chip *l_gpio_line_get_chip(struct l_gpio_line *gpio_line);
const char *l_gpio_line_get_label(struct l_gpio_line *line);
They are WIP, though.
so I am not 100% sure this is useful since it adds a complexity that most like is never
going to be used. What I would first check is what happens when the underlying physical
device goes away. Does the l_gpio_chip fd gets a HUP signal. Since we might really need to
allow for disconnect callback here.
I am fine with the lines being address with the uint32 index number. Creating a struct for
it seems kinda useless since you will always need special knowledge to some degree anyway.
I rather have l_gpio_chip_find_line that takes a line label and tries to find it.
Especially with the background you might need to set more than one GPIO at once, then the
line concept blows up.
>>> You have the main /dev/chip file descriptor and you have
a file descriptor returned from the GPIO_GET_LINEHANDLE_IOCTL. What happens to the fds
returned by GPIO_GET_LINEHANDLE_IOCTL if the main /dev/chip fd is closed?
>> The virtual fds from GPIO_GET_LINEHANDLE_IOCTL stays valid after closing the
/dev/gpiochipX fd. (So I should probably close those virtual fds after getting/setting the
> So if this is the case, do we even need to worry about reference tracking between
gpio_chip and gpio_line?
> Perhaps all we need is a gpio_chip_info internal structure that can be reference
counted and used by gpio_chip and gpio_line. And gpio_chip and gpio_line objects can be
destroyed independently of each other.
Is there generic reference counting functionality in ell?
How much of the kernel API do we want to expose? Limiting ourselves to setting/getting a
single gpio-line at the time is clearly the simplest, but I wonder how long it will be
before someone requests support for handling multiple lines with a single structure (as is
possible with the gpiohandle_request structure in the kernel API).
>>> There's no hotplug/unplug with gpio devices right? So you can count of
the /dev/chip & fd to be owned exlusively by the ell client?
>> You can get USB gpio expanders:
>> So I guess /dev/gpiochipX nodes can come and go.
> Probably out of scope for this simple API, just curious: how do we detect that?
It sound like a job for udev, yes.
If the HUP is actually signaled on the /dev/gpiochipX fd, then I would ignore udev. And
instead add a helper to find a given l_gpio_chip_new_from_name() that then would walk
either /dev/ (with scandir like libgpiod does) or by going through sysfs. I would prefer
sysfs since it will be mostly part of a bus or class.
>> Multiple processes can use the same gpiochip, but only one process can request a
> How do you define 'use the same gpiochip'?
Opening e.g. /dev/gpiochip0 can happen in parallel, but requesting a handle/virtual fd to
gpioline0 on gpiochip0 is serialized.
I would just allow opening /dev/gpiochipX multiple times. I think there is not need for
ELL to multiplex here.
For one-shot triggers we could do a l_gpio_set(const char *chipname, const char *linename)
that then will try to find the chip and line by name and toggle it.