| Message ID | 20191219171528.6348-13-brgl@bgdev.pl |
|---|---|
| State | New |
| Headers | show |
| Series | gpiolib: add an ioctl() for monitoring line status changes | expand |
On Thu, Dec 19, 2019 at 06:15:27PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > Currently there is no way for user-space to be informed about changes > in status of GPIO lines e.g. when someone else requests the line or its > config changes. We can only periodically re-read the line-info. This > is fine for simple one-off user-space tools, but any daemon that provides > a centralized access to GPIO chips would benefit hugely from an event > driven line info synchronization. > > This patch adds a new ioctl() that allows user-space processes to reuse > the file descriptor associated with the character device for watching > any changes in line properties. Every such event contains the updated > line information. > > Currently the events are generated on three types of status changes: when > a line is requested, when it's released and when its config is changed. > The first two are self-explanatory. For the third one: this will only > happen when another user-space process calls the new SET_CONFIG ioctl() > as any changes that can happen from within the kernel (i.e. > set_transitory() or set_debounce()) are of no interest to user-space. > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > --- > drivers/gpio/gpiolib.c | 191 ++++++++++++++++++++++++++++++++++++-- > drivers/gpio/gpiolib.h | 1 + > include/uapi/linux/gpio.h | 24 +++++ > tools/gpio/gpio-watch | Bin 0 -> 26528 bytes Did you mean for this binary file to be checked in?
On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > Currently there is no way for user-space to be informed about changes > in status of GPIO lines e.g. when someone else requests the line or its > config changes. We can only periodically re-read the line-info. This > is fine for simple one-off user-space tools, but any daemon that provides > a centralized access to GPIO chips would benefit hugely from an event > driven line info synchronization. > > This patch adds a new ioctl() that allows user-space processes to reuse > the file descriptor associated with the character device for watching > any changes in line properties. Every such event contains the updated > line information. > > Currently the events are generated on three types of status changes: when > a line is requested, when it's released and when its config is changed. > The first two are self-explanatory. For the third one: this will only > happen when another user-space process calls the new SET_CONFIG ioctl() > as any changes that can happen from within the kernel (i.e. > set_transitory() or set_debounce()) are of no interest to user-space. > - } else if (cmd == GPIO_GET_LINEINFO_IOCTL) { > + } else if (cmd == GPIO_GET_LINEINFO_IOCTL || > + cmd == GPIO_GET_LINEINFO_WATCH_IOCTL) { Wouldn't be better for maintenance to have them separated from the day 1? ... > + if (test_bit(desc_to_gpio(desc), priv->watched_lines)) { if (!test_bit(...)) return NOTIFY_DONE; ? > + pr_debug_ratelimited( > + "%s: lineinfo event FIFO is full - event dropped\n", > + __func__); This is in 99.9% cases redundant in *_dbg() calls. > + ret = NOTIFY_OK; > + } > + > + return ret; return NOTIFY_OK; ? > +} ... > @@ -3111,6 +3285,7 @@ static int gpio_set_bias(struct gpio_chip *chip, struct gpio_desc *desc) > if (ret != -ENOTSUPP) > return ret; > } > + > return 0; > } > This hunk doesn't belong to this patch. ... > +/** > + * struct gpioline_info_changed - Information about a change in status > + * of a GPIO line > + * @info: updated line information > + * @timestamp: estimate of time of status change occurrence, in nanoseconds > + * and GPIOLINE_CHANGED_CONFIG > + * @event_type: one of GPIOLINE_CHANGED_REQUESTED, GPIOLINE_CHANGED_RELEASED > + */ > +struct gpioline_info_changed { > + struct gpioline_info info; Is this guaranteed to be always 8 byte aligned? I'm expecting to see some comments there and / or here about it. > + __u64 timestamp; > + __u32 event_type; > + __u32 padding[5]; /* for future use */ > +};
czw., 19 gru 2019 o 18:24 Greg Kroah-Hartman <gregkh@linuxfoundation.org> napisał(a): > > On Thu, Dec 19, 2019 at 06:15:27PM +0100, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > Currently there is no way for user-space to be informed about changes > > in status of GPIO lines e.g. when someone else requests the line or its > > config changes. We can only periodically re-read the line-info. This > > is fine for simple one-off user-space tools, but any daemon that provides > > a centralized access to GPIO chips would benefit hugely from an event > > driven line info synchronization. > > > > This patch adds a new ioctl() that allows user-space processes to reuse > > the file descriptor associated with the character device for watching > > any changes in line properties. Every such event contains the updated > > line information. > > > > Currently the events are generated on three types of status changes: when > > a line is requested, when it's released and when its config is changed. > > The first two are self-explanatory. For the third one: this will only > > happen when another user-space process calls the new SET_CONFIG ioctl() > > as any changes that can happen from within the kernel (i.e. > > set_transitory() or set_debounce()) are of no interest to user-space. > > > > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > --- > > drivers/gpio/gpiolib.c | 191 ++++++++++++++++++++++++++++++++++++-- > > drivers/gpio/gpiolib.h | 1 + > > include/uapi/linux/gpio.h | 24 +++++ > > tools/gpio/gpio-watch | Bin 0 -> 26528 bytes > > Did you mean for this binary file to be checked in? > No, of course not, it's a mistake. I'll remove it in v4. Bart
czw., 19 gru 2019 o 19:17 Andy Shevchenko <andy.shevchenko@gmail.com> napisał(a): > > On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > Currently there is no way for user-space to be informed about changes > > in status of GPIO lines e.g. when someone else requests the line or its > > config changes. We can only periodically re-read the line-info. This > > is fine for simple one-off user-space tools, but any daemon that provides > > a centralized access to GPIO chips would benefit hugely from an event > > driven line info synchronization. > > > > This patch adds a new ioctl() that allows user-space processes to reuse > > the file descriptor associated with the character device for watching > > any changes in line properties. Every such event contains the updated > > line information. > > > > Currently the events are generated on three types of status changes: when > > a line is requested, when it's released and when its config is changed. > > The first two are self-explanatory. For the third one: this will only > > happen when another user-space process calls the new SET_CONFIG ioctl() > > as any changes that can happen from within the kernel (i.e. > > set_transitory() or set_debounce()) are of no interest to user-space. > > > - } else if (cmd == GPIO_GET_LINEINFO_IOCTL) { > > + } else if (cmd == GPIO_GET_LINEINFO_IOCTL || > > + cmd == GPIO_GET_LINEINFO_WATCH_IOCTL) { > > Wouldn't be better for maintenance to have them separated from the day 1? > Sure. Will fix in v4. > ... > > > + if (test_bit(desc_to_gpio(desc), priv->watched_lines)) { > > if (!test_bit(...)) > return NOTIFY_DONE; > > ? > > > + pr_debug_ratelimited( > > + "%s: lineinfo event FIFO is full - event dropped\n", > > > + __func__); > > This is in 99.9% cases redundant in *_dbg() calls. > > > + ret = NOTIFY_OK; > > + } > > + > > + return ret; > > return NOTIFY_OK; Yeah, makes sense. > ? > > > +} > > ... > > > @@ -3111,6 +3285,7 @@ static int gpio_set_bias(struct gpio_chip *chip, struct gpio_desc *desc) > > if (ret != -ENOTSUPP) > > return ret; > > } > > + > > return 0; > > } > > > > This hunk doesn't belong to this patch. > Ha! Of course it doesn't. :) > ... > > > +/** > > + * struct gpioline_info_changed - Information about a change in status > > + * of a GPIO line > > + * @info: updated line information > > + * @timestamp: estimate of time of status change occurrence, in nanoseconds > > + * and GPIOLINE_CHANGED_CONFIG > > + * @event_type: one of GPIOLINE_CHANGED_REQUESTED, GPIOLINE_CHANGED_RELEASED > > + */ > > +struct gpioline_info_changed { > > > + struct gpioline_info info; > > Is this guaranteed to be always 8 byte aligned? > I'm expecting to see some comments there and / or here about it. > struct gpioline_info alone is 32-bit aligned but its size is 72 bytes which works for 64-bit alignment. This new structure's biggest element in 64-bit, so it's 64-bit aligned on 64-bit arch. We have 72 bytes of gpioline_info, 8 bytes of timestamp, 32 bytes of event type and 5 * 32 bytes of padding. Should be fine, but I'll add comments to the header. Bart > > + __u64 timestamp; > > + __u32 event_type; > > + __u32 padding[5]; /* for future use */ > > +}; > > -- > With Best Regards, > Andy Shevchenko
On Fri, Dec 20, 2019 at 12:25:59PM +0100, Bartosz Golaszewski wrote: > czw., 19 gru 2019 o 19:17 Andy Shevchenko <andy.shevchenko@gmail.com> > napisał(a): > > On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: ... > > > +/** > > > + * struct gpioline_info_changed - Information about a change in status > > > + * of a GPIO line > > > + * @info: updated line information > > > + * @timestamp: estimate of time of status change occurrence, in nanoseconds > > > + * and GPIOLINE_CHANGED_CONFIG > > > + * @event_type: one of GPIOLINE_CHANGED_REQUESTED, GPIOLINE_CHANGED_RELEASED > > > + */ > > > +struct gpioline_info_changed { > > > > > + struct gpioline_info info; > > > > Is this guaranteed to be always 8 byte aligned? > > I'm expecting to see some comments there and / or here about it. > > > > struct gpioline_info alone is 32-bit aligned but its size is 72 bytes > which works for 64-bit alignment. This new structure's biggest element > in 64-bit, so it's 64-bit aligned on 64-bit arch. We have 72 bytes of > gpioline_info, 8 bytes of timestamp, 32 bytes of event type and 5 * 32 > bytes of padding. Should be fine, but I'll add comments to the header. Yes, what I meant is to add comment at least to struct gpioline_info definition that if somebody would like to change it there (which also might be a problematic here, if there is no versioning scheme / length member). > > > + __u64 timestamp; > > > + __u32 event_type; > > > + __u32 padding[5]; /* for future use */ > > > +}; Offtopic a bit, had you had a chance to look at Buildroot and our scripts I shared?
pt., 20 gru 2019 o 13:15 Andy Shevchenko <andy.shevchenko@gmail.com> napisał(a): > > On Fri, Dec 20, 2019 at 12:25:59PM +0100, Bartosz Golaszewski wrote: > > czw., 19 gru 2019 o 19:17 Andy Shevchenko <andy.shevchenko@gmail.com> > > napisał(a): > > > On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > ... > > > > > +/** > > > > + * struct gpioline_info_changed - Information about a change in status > > > > + * of a GPIO line > > > > + * @info: updated line information > > > > + * @timestamp: estimate of time of status change occurrence, in nanoseconds > > > > + * and GPIOLINE_CHANGED_CONFIG > > > > + * @event_type: one of GPIOLINE_CHANGED_REQUESTED, GPIOLINE_CHANGED_RELEASED > > > > + */ > > > > +struct gpioline_info_changed { > > > > > > > + struct gpioline_info info; > > > > > > Is this guaranteed to be always 8 byte aligned? > > > I'm expecting to see some comments there and / or here about it. > > > > > > > struct gpioline_info alone is 32-bit aligned but its size is 72 bytes > > which works for 64-bit alignment. This new structure's biggest element > > in 64-bit, so it's 64-bit aligned on 64-bit arch. We have 72 bytes of > > gpioline_info, 8 bytes of timestamp, 32 bytes of event type and 5 * 32 > > bytes of padding. Should be fine, but I'll add comments to the header. > > Yes, what I meant is to add comment at least to struct gpioline_info definition > that if somebody would like to change it there (which also might be a > problematic here, if there is no versioning scheme / length member). > > > > > + __u64 timestamp; > > > > + __u32 event_type; > > > > + __u32 padding[5]; /* for future use */ > > > > +}; > > Offtopic a bit, had you had a chance to look at Buildroot and our scripts > I shared? > Not yet, I'll do that over the weekend. Bart
czw., 19 gru 2019 o 19:17 Andy Shevchenko <andy.shevchenko@gmail.com> napisał(a): > > On Thu, Dec 19, 2019 at 7:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com> > > > > Currently there is no way for user-space to be informed about changes > > in status of GPIO lines e.g. when someone else requests the line or its > > config changes. We can only periodically re-read the line-info. This > > is fine for simple one-off user-space tools, but any daemon that provides > > a centralized access to GPIO chips would benefit hugely from an event > > driven line info synchronization. > > > > This patch adds a new ioctl() that allows user-space processes to reuse > > the file descriptor associated with the character device for watching > > any changes in line properties. Every such event contains the updated > > line information. > > > > Currently the events are generated on three types of status changes: when > > a line is requested, when it's released and when its config is changed. > > The first two are self-explanatory. For the third one: this will only > > happen when another user-space process calls the new SET_CONFIG ioctl() > > as any changes that can happen from within the kernel (i.e. > > set_transitory() or set_debounce()) are of no interest to user-space. > > > - } else if (cmd == GPIO_GET_LINEINFO_IOCTL) { > > + } else if (cmd == GPIO_GET_LINEINFO_IOCTL || > > + cmd == GPIO_GET_LINEINFO_WATCH_IOCTL) { > > Wouldn't be better for maintenance to have them separated from the day 1? > I think this would lead to a lot of code duplication. I left it as it is is v4. Bart
pt., 20 gru 2019 o 18:29 Bartosz Golaszewski <bgolaszewski@baylibre.com> napisał(a): > > > > struct gpioline_info alone is 32-bit aligned but its size is 72 bytes > > > which works for 64-bit alignment. This new structure's biggest element > > > in 64-bit, so it's 64-bit aligned on 64-bit arch. We have 72 bytes of > > > gpioline_info, 8 bytes of timestamp, 32 bytes of event type and 5 * 32 > > > bytes of padding. Should be fine, but I'll add comments to the header. > > > > Yes, what I meant is to add comment at least to struct gpioline_info definition > > that if somebody would like to change it there (which also might be a > > problematic here, if there is no versioning scheme / length member). > > > > > > > + __u64 timestamp; > > > > > + __u32 event_type; > > > > > + __u32 padding[5]; /* for future use */ > > > > > +}; > > > > Offtopic a bit, had you had a chance to look at Buildroot and our scripts > > I shared? > > > > Not yet, I'll do that over the weekend. Now tested using the buildroot image you posted. Thanks for that, I'll make sure to use it to test the v2 API for lineevents. Bart
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 41abf17640de..a422086e6973 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -547,6 +547,9 @@ static long linehandle_set_config(struct linehandle_state *lh, if (ret) return ret; } + + atomic_notifier_call_chain(&desc->gdev->notifier, + GPIOLINE_CHANGED_CONFIG, desc); } return 0; } @@ -1203,14 +1206,25 @@ static void gpio_desc_to_lineinfo(struct gpio_desc *desc, spin_unlock_irqrestore(&gpio_lock, flags); } +struct gpio_chardev_data { + struct gpio_device *gdev; + wait_queue_head_t wait; + DECLARE_KFIFO(events, struct gpioline_info_changed, 32); + struct notifier_block lineinfo_changed_nb; + unsigned long *watched_lines; +}; + /* * gpio_ioctl() - ioctl handler for the GPIO chardev */ static long gpio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { - struct gpio_device *gdev = filp->private_data; + struct gpio_chardev_data *priv = filp->private_data; + struct gpio_device *gdev = priv->gdev; struct gpio_chip *chip = gdev->chip; void __user *ip = (void __user *)arg; + struct gpio_desc *desc; + __u32 offset; /* We fail any subsequent ioctl():s when the chip is gone */ if (!chip) @@ -1232,9 +1246,9 @@ static long gpio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) if (copy_to_user(ip, &chipinfo, sizeof(chipinfo))) return -EFAULT; return 0; - } else if (cmd == GPIO_GET_LINEINFO_IOCTL) { + } else if (cmd == GPIO_GET_LINEINFO_IOCTL || + cmd == GPIO_GET_LINEINFO_WATCH_IOCTL) { struct gpioline_info lineinfo; - struct gpio_desc *desc; if (copy_from_user(&lineinfo, ip, sizeof(lineinfo))) return -EFAULT; @@ -1247,11 +1261,25 @@ static long gpio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) if (copy_to_user(ip, &lineinfo, sizeof(lineinfo))) return -EFAULT; + + if (cmd == GPIO_GET_LINEINFO_WATCH_IOCTL) + set_bit(desc_to_gpio(desc), priv->watched_lines); + return 0; } else if (cmd == GPIO_GET_LINEHANDLE_IOCTL) { return linehandle_create(gdev, ip); } else if (cmd == GPIO_GET_LINEEVENT_IOCTL) { return lineevent_create(gdev, ip); + } else if (cmd == GPIO_GET_LINEINFO_UNWATCH_IOCTL) { + if (copy_from_user(&offset, ip, sizeof(offset))) + return -EFAULT; + + desc = gpiochip_get_desc(chip, offset); + if (IS_ERR(desc)) + return PTR_ERR(desc); + + clear_bit(desc_to_gpio(desc), &desc->flags); + return 0; } return -EINVAL; } @@ -1264,6 +1292,105 @@ static long gpio_ioctl_compat(struct file *filp, unsigned int cmd, } #endif +static struct gpio_chardev_data * +to_gpio_chardev_data(struct notifier_block *nb) +{ + return container_of(nb, struct gpio_chardev_data, lineinfo_changed_nb); +} + +static int lineinfo_changed_notify(struct notifier_block *nb, + unsigned long action, void *data) +{ + struct gpio_chardev_data *priv = to_gpio_chardev_data(nb); + struct gpioline_info_changed chg; + struct gpio_desc *desc = data; + int ret = NOTIFY_DONE; + + if (test_bit(desc_to_gpio(desc), priv->watched_lines)) { + memset(&chg, 0, sizeof(chg)); + chg.info.line_offset = gpio_chip_hwgpio(desc); + chg.event_type = action; + chg.timestamp = ktime_get_real_ns(); + gpio_desc_to_lineinfo(desc, &chg.info); + + ret = kfifo_in_spinlocked(&priv->events, &chg, + 1, &priv->wait.lock); + if (ret) + wake_up_poll(&priv->wait, EPOLLIN); + else + pr_debug_ratelimited( + "%s: lineinfo event FIFO is full - event dropped\n", + __func__); + + ret = NOTIFY_OK; + } + + return ret; +} + +static __poll_t lineinfo_watch_poll(struct file *filep, + struct poll_table_struct *pollt) +{ + struct gpio_chardev_data *priv = filep->private_data; + __poll_t events = 0; + + poll_wait(filep, &priv->wait, pollt); + + if (!kfifo_is_empty_spinlocked_noirqsave(&priv->events, + &priv->wait.lock)) + events = EPOLLIN | EPOLLRDNORM; + + return events; +} + +static ssize_t lineinfo_watch_read(struct file *filep, char __user *buf, + size_t count, loff_t *off) +{ + struct gpio_chardev_data *priv = filep->private_data; + struct gpioline_info_changed event; + ssize_t bytes_read = 0; + int ret; + + if (count < sizeof(event)) + return -EINVAL; + + do { + spin_lock(&priv->wait.lock); + if (kfifo_is_empty(&priv->events)) { + if (bytes_read) { + spin_unlock(&priv->wait.lock); + return bytes_read; + } + + if (filep->f_flags & O_NONBLOCK) { + spin_unlock(&priv->wait.lock); + return -EAGAIN; + } + + ret = wait_event_interruptible_locked(priv->wait, + !kfifo_is_empty(&priv->events)); + if (ret) { + spin_unlock(&priv->wait.lock); + return ret; + } + } + + ret = kfifo_out(&priv->events, &event, 1); + spin_unlock(&priv->wait.lock); + if (ret != 1) { + ret = -EIO; + break; + /* We should never get here. See lineevent_read(). */ + } + + if (copy_to_user(buf + bytes_read, &event, sizeof(event))) + return -EFAULT; + bytes_read += sizeof(event); + } while (count >= bytes_read + sizeof(event)); + + return bytes_read; +} + /** * gpio_chrdev_open() - open the chardev for ioctl operations * @inode: inode for this chardev @@ -1274,14 +1401,48 @@ static int gpio_chrdev_open(struct inode *inode, struct file *filp) { struct gpio_device *gdev = container_of(inode->i_cdev, struct gpio_device, chrdev); + struct gpio_chardev_data *priv; + int ret = -ENOMEM; /* Fail on open if the backing gpiochip is gone */ if (!gdev->chip) return -ENODEV; + + priv = kzalloc(sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + priv->watched_lines = bitmap_zalloc(gdev->chip->ngpio, GFP_KERNEL); + if (!priv->watched_lines) + goto out_free_priv; + + init_waitqueue_head(&priv->wait); + INIT_KFIFO(priv->events); + priv->gdev = gdev; + + priv->lineinfo_changed_nb.notifier_call = lineinfo_changed_notify; + ret = atomic_notifier_chain_register(&gdev->notifier, + &priv->lineinfo_changed_nb); + if (ret) + goto out_free_bitmap; + get_device(&gdev->dev); - filp->private_data = gdev; + filp->private_data = priv; + + ret = nonseekable_open(inode, filp); + if (ret) + goto out_unregister_notifier; + + return ret; - return nonseekable_open(inode, filp); +out_unregister_notifier: + atomic_notifier_chain_unregister(&gdev->notifier, + &priv->lineinfo_changed_nb); +out_free_bitmap: + bitmap_free(priv->watched_lines); +out_free_priv: + kfree(priv); + return ret; } /** @@ -1292,17 +1453,23 @@ static int gpio_chrdev_open(struct inode *inode, struct file *filp) */ static int gpio_chrdev_release(struct inode *inode, struct file *filp) { - struct gpio_device *gdev = container_of(inode->i_cdev, - struct gpio_device, chrdev); + struct gpio_chardev_data *priv = filp->private_data; + struct gpio_device *gdev = priv->gdev; + bitmap_free(priv->watched_lines); + atomic_notifier_chain_unregister(&gdev->notifier, + &priv->lineinfo_changed_nb); put_device(&gdev->dev); + kfree(priv); + return 0; } - static const struct file_operations gpio_fileops = { .release = gpio_chrdev_release, .open = gpio_chrdev_open, + .poll = lineinfo_watch_poll, + .read = lineinfo_watch_read, .owner = THIS_MODULE, .llseek = no_llseek, .unlocked_ioctl = gpio_ioctl, @@ -1513,6 +1680,8 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, void *data, for (i = 0; i < chip->ngpio; i++) gdev->descs[i].gdev = gdev; + ATOMIC_INIT_NOTIFIER_HEAD(&gdev->notifier); + #ifdef CONFIG_PINCTRL INIT_LIST_HEAD(&gdev->pin_ranges); #endif @@ -2852,6 +3021,8 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label) } done: spin_unlock_irqrestore(&gpio_lock, flags); + atomic_notifier_call_chain(&desc->gdev->notifier, + GPIOLINE_CHANGED_REQUESTED, desc); return ret; } @@ -2949,6 +3120,9 @@ static bool gpiod_free_commit(struct gpio_desc *desc) } spin_unlock_irqrestore(&gpio_lock, flags); + atomic_notifier_call_chain(&desc->gdev->notifier, + GPIOLINE_CHANGED_RELEASED, desc); + return ret; } @@ -3111,6 +3285,7 @@ static int gpio_set_bias(struct gpio_chip *chip, struct gpio_desc *desc) if (ret != -ENOTSUPP) return ret; } + return 0; } diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h index a1cbeabadc69..8e3969616cfe 100644 --- a/drivers/gpio/gpiolib.h +++ b/drivers/gpio/gpiolib.h @@ -54,6 +54,7 @@ struct gpio_device { const char *label; void *data; struct list_head list; + struct atomic_notifier_head notifier; #ifdef CONFIG_PINCTRL /* diff --git a/include/uapi/linux/gpio.h b/include/uapi/linux/gpio.h index 799cf823d493..a37ad3d97c8d 100644 --- a/include/uapi/linux/gpio.h +++ b/include/uapi/linux/gpio.h @@ -59,6 +59,28 @@ struct gpioline_info { /* Maximum number of requested handles */ #define GPIOHANDLES_MAX 64 +/* Possible line status change events */ +enum { + GPIOLINE_CHANGED_REQUESTED = 1, + GPIOLINE_CHANGED_RELEASED, + GPIOLINE_CHANGED_CONFIG, +}; + +/** + * struct gpioline_info_changed - Information about a change in status + * of a GPIO line + * @info: updated line information + * @timestamp: estimate of time of status change occurrence, in nanoseconds + * and GPIOLINE_CHANGED_CONFIG + * @event_type: one of GPIOLINE_CHANGED_REQUESTED, GPIOLINE_CHANGED_RELEASED + */ +struct gpioline_info_changed { + struct gpioline_info info; + __u64 timestamp; + __u32 event_type; + __u32 padding[5]; /* for future use */ +}; + /* Linerequest flags */ #define GPIOHANDLE_REQUEST_INPUT (1UL << 0) #define GPIOHANDLE_REQUEST_OUTPUT (1UL << 1) @@ -176,6 +198,8 @@ struct gpioevent_data { #define GPIO_GET_CHIPINFO_IOCTL _IOR(0xB4, 0x01, struct gpiochip_info) #define GPIO_GET_LINEINFO_IOCTL _IOWR(0xB4, 0x02, struct gpioline_info) +#define GPIO_GET_LINEINFO_WATCH_IOCTL _IOWR(0xB4, 0x0b, struct gpioline_info) +#define GPIO_GET_LINEINFO_UNWATCH_IOCTL _IOWR(0xB4, 0x0c, __u32) #define GPIO_GET_LINEHANDLE_IOCTL _IOWR(0xB4, 0x03, struct gpiohandle_request) #define GPIO_GET_LINEEVENT_IOCTL _IOWR(0xB4, 0x04, struct gpioevent_request) diff --git a/tools/gpio/gpio-watch b/tools/gpio/gpio-watch new file mode 100755 index 0000000000000000000000000000000000000000..d67bf021afad6b6eec40cf10b673c5127e55b0da