On 17/12/2018 20.19, Denis Kenzior wrote:
> struct l_gpio_line *l_gpio_find_line(const char *line_label);
How does that work?
It does a scandir on /dev/ filtering on "gpiochip" and then traverses
each line on each found gpiochip - pretty much like libgpiod does:
> struct l_gpio_chip *l_gpio_line_get_chip(struct l_gpio_line
This might be tricky depending on how you setup the tracking
relationship between line & chip.
If we put the primary fd in the internal gpio structure, this function
could create a new struct l_gpio_chip using GPIO_GET_CHIPINFO_IOCTL. But
I should probably postpone that to later.
>> So if this is the case, do we even need to worry about
>> 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?
No, but ell is not thread safe, so you can just simply use a counter.
Some of our classes use __sync_sub_and_fetch, but that is really
overkill and pointless.
I started out with this:
static struct l_gpio *gpio_get(struct l_gpio *gpio)
static void gpio_put(struct l_gpio *gpio)
if (--gpio->refcount == 0)
> How much of the kernel API do we want to expose? Limiting
> 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).
I think the immediate goal is to get enough into ell so that you can
work on your oFono bits. We can then go on from there.
Embedded Linux Consultant
+45 61 65 54 61