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
Okay, so I'm guessing we might need to expose this in the future somehow.
> 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 values.)
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.
> 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? udev?
Multiple processes can use the same gpiochip, but only one process can
request a line handle.
How do you define 'use the same gpiochip'?