>> I previously submitted pacthes[1] for the Quectel M95 modem, and now >> finally have the time needed to address the review comments. >> >> In the meantime, my hardware has changed (modem chip remains the same >> though), and so I would like to add more generic power management the >> ofono driver. >> >> I would assume that I cannot be the first with the urge to control >> modem power using GPIOs (found one example in >> ofono/plugins/nokia-gpio.c), so > > Maybe not the first, but nobody has brought this up for oh ~8 years or > so. So might as well treat yourself as the first ;) I see.. Maybe I will not be the last then :)

>> it might make sense to add GPIO helper in a common object, and use >> libgpiod in there? > > We will not be adding any further dependencies on GLib based libraries > for oFono as GLib use is going to be deprecated over time (in favor of > ell). This is especially true for a small library like libgpiod. I don't think libgpiod i GLib based: ldd /usr/lib/libgpiod.so linux-vdso.so.1 (0x00007ffe90977000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f325b3d4000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f325b5b4000) > So this has to be done either inside oFono itself or preferably as a set > of class(es) inside ell. As long as it is only a matter of setting a single GPIO on/off, then I think a helper in common/gpio.{c,h} should be enough - something like this from my little test program: static bool gpio_set(uint32_t chip, uint32_t line, uint8_t value) { struct gpiohandle_request req = {0}; char path[] = "/dev/gpiochipXX"; int ret, fd; snprintf(path, sizeof(path), "/dev/gpiochip%u", chip); fd = open(path, O_RDWR | O_CLOEXEC); if (fd < 0) { error(0, errno, "open: %s", path); return false; } req.lineoffsets[0] = line; req.lines = 1; req.flags = GPIOHANDLE_REQUEST_OUTPUT; req.default_values[0] = !!value; strncpy(req.consumer_label, "ofono", sizeof(req.consumer_label)); ret = ioctl(fd, GPIO_GET_LINEHANDLE_IOCTL, &req); if (ret < 0) { error(0, errno, "ioctl"); return false; } return true; }

>> If that would be acceptable, a way to configure such GPIO >> numbers/names is needed. Should this be done with an OFONO_CONFIG env >> attribute in the udev rules? > > That is ultimately up to the driver. Serial devices have to rely on > udev rules or configuration files, so either should be fine. udev rules it is then