From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: lakshmi.sowjanya.d@intel.com
Cc: Linus Walleij <linus.walleij@linaro.org>,
linux-gpio <linux-gpio@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
mgross@linux.intel.com,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
tamal.saha@intel.com, bala.senthil@intel.com,
Kent Gibson <warthog618@gmail.com>
Subject: Re: [RFC PATCH v1 02/20] gpio: Add GPIO polling interface to GPIO lib
Date: Wed, 22 Sep 2021 12:03:53 +0200 [thread overview]
Message-ID: <CAMpxmJWeZP-f-3BoWwX7PkWNZySn5RP=rc4cVyLEwYmSb6if+w@mail.gmail.com> (raw)
In-Reply-To: <20210824164801.28896-3-lakshmi.sowjanya.d@intel.com>
On Tue, Aug 24, 2021 at 6:48 PM <lakshmi.sowjanya.d@intel.com> wrote:
>
> From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
>
> Some Intel Timed I/O devices do not implement IRQ functionality. Augment
> read() interface to allow polling.
>
> Add two GPIO device methods: setup_poll() and poll():
> - setup_poll() configures the GPIO interface e.g. capture rising edges
> - poll() checks for events on the interface
>
> To implement polling, the driver must implement the two functions above
> and should either leave to_irq() method NULL or return irq 0.
>
> setup_poll() should configure the hardware to 'listen' for input events.
>
> poll() driver implementation must return the realtime timestamp
> corresponding to the event and -EAGAIN if no data is available.
>
> Co-developed-by: Christopher Hall <christopher.s.hall@intel.com>
> Signed-off-by: Christopher Hall <christopher.s.hall@intel.com>
> Signed-off-by: Tamal Saha <tamal.saha@intel.com>
> Signed-off-by: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
> Reviewed-by: Mark Gross <mgross@linux.intel.com>
> ---
Interesting. So the idea is to allow user-space to read line events as
if they were generated by interrupts handled in the kernel. While this
whole series has a long way to go and this patch looks wrong to me in
several places at first glance, I find the idea interesting. Cc'ing
Kent who's the author of most of this code - Kent: what do you think?
Bart
> drivers/gpio/gpiolib-cdev.c | 28 ++++++++++++++++++++++++++--
> include/linux/gpio/driver.h | 19 +++++++++++++++++++
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c
> index c7b5446d01fd..4741bf34750b 100644
> --- a/drivers/gpio/gpiolib-cdev.c
> +++ b/drivers/gpio/gpiolib-cdev.c
> @@ -1227,13 +1227,34 @@ static ssize_t linereq_read(struct file *file,
> loff_t *f_ps)
Why would you do this in linereq_read()? Userspace ends up in
linereq_poll() when it calls poll().
> {
> struct linereq *lr = file->private_data;
> + struct gpioevent_poll_data poll_data;
> struct gpio_v2_line_event le;
> ssize_t bytes_read = 0;
> - int ret;
> + int ret, offset;
>
> if (count < sizeof(le))
> return -EINVAL;
>
> + /* Without an IRQ, we can only poll */
> + offset = gpio_chip_hwgpio(lr->gdev->descs);
> + if (lr->lines[offset].irq == 0) {
> + struct gpio_v2_line_event *event;
> +
> + if (!(file->f_flags & O_NONBLOCK))
> + return -ENODEV;
> +
> + ret = lr->gdev->chip->do_poll(lr->gdev->chip, offset,
> + lr->lines[offset].eflags, &poll_data);
What if the driver doesn't implement do_poll()?
> + if (ret)
> + return ret;
> + event = kzalloc(sizeof(*event), GFP_KERNEL);
> + event->timestamp_ns = poll_data.timestamp;
> + event->id = poll_data.id;
> + if (copy_to_user(buf, (void *)&event, sizeof(event)))
> + return -EFAULT;
> + return sizeof(event);
> + }
> +
> do {
> spin_lock(&lr->wait.lock);
> if (kfifo_is_empty(&lr->events)) {
> @@ -1314,6 +1335,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> {
> struct gpio_v2_line_request ulr;
> struct gpio_v2_line_config *lc;
> + unsigned int file_flags;
> struct linereq *lr;
> struct file *file;
> u64 flags;
> @@ -1411,6 +1433,8 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> goto out_free_linereq;
> }
>
> + file_flags = O_RDONLY | O_CLOEXEC;
> +
> blocking_notifier_call_chain(&desc->gdev->notifier,
> GPIO_V2_LINE_CHANGED_REQUESTED, desc);
>
> @@ -1425,7 +1449,7 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip)
> }
>
> file = anon_inode_getfile("gpio-line", &line_fileops, lr,
> - O_RDONLY | O_CLOEXEC);
> + file_flags);
> if (IS_ERR(file)) {
> ret = PTR_ERR(file);
> goto out_put_unused_fd;
> diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
> index 3a268781fcec..f5b971ad40bc 100644
> --- a/include/linux/gpio/driver.h
> +++ b/include/linux/gpio/driver.h
> @@ -17,6 +17,7 @@ struct device_node;
> struct seq_file;
> struct gpio_device;
> struct module;
> +struct gpioevent_poll_data;
> enum gpiod_flags;
> enum gpio_lookup_flags;
>
> @@ -304,6 +305,11 @@ struct gpio_irq_chip {
> * @add_pin_ranges: optional routine to initialize pin ranges, to be used when
> * requires special mapping of the pins that provides GPIO functionality.
> * It is called after adding GPIO chip and before adding IRQ chip.
> + * @setup_poll: optional routine for devices that don't support interrupts.
> + * Takes flags argument as in/out parameter, where caller requests
> + * event flags and driver returns accepted flags.
> + * @do_poll: optional routine for devices that don't support interrupts.
> + * Returns event specification in data parameter.
> * @base: identifies the first GPIO number handled by this chip;
> * or, if negative during registration, requests dynamic ID allocation.
> * DEPRECATION: providing anything non-negative and nailing the base
> @@ -396,6 +402,14 @@ struct gpio_chip {
>
> int (*add_pin_ranges)(struct gpio_chip *gc);
>
> + int (*setup_poll)(struct gpio_chip *chip,
> + unsigned int offset,
> + u32 *eflags);
Does anyone even call this?
> +
> + int (*do_poll)(struct gpio_chip *chip,
> + unsigned int offset, u32 eflags,
> + struct gpioevent_poll_data *data);
> +
> int base;
> u16 ngpio;
> const char *const *names;
> @@ -471,6 +485,11 @@ struct gpio_chip {
> #endif /* CONFIG_OF_GPIO */
> };
>
> +struct gpioevent_poll_data {
> + __u64 timestamp;
> + __u32 id;
> +};
> +
> extern const char *gpiochip_is_requested(struct gpio_chip *gc,
> unsigned int offset);
>
> --
> 2.17.1
>
This patch doesn't look good - or even tested - but as I said - the
idea itself sounds reasonable in general.
Bart
next prev parent reply other threads:[~2021-09-22 10:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 16:47 [RFC PATCH v1 00/20] Review Request: Add support for Intel PMC lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 01/20] gpio: Add basic GPIO driver for Intel PMC Timed I/O device lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 02/20] gpio: Add GPIO polling interface to GPIO lib lakshmi.sowjanya.d
2021-09-22 10:03 ` Bartosz Golaszewski [this message]
2021-10-07 2:14 ` Kent Gibson
2021-08-24 16:47 ` [RFC PATCH v1 03/20] arch: x86: Add ART support function to tsc code lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 04/20] gpio: Add input code to Intel PMC Timed I/O Driver lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 05/20] tools: gpio: Add additional polling support to gpio-event-mon lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 06/20] gpio: Add set_input and polling interface to GPIO lib code lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 07/20] gpio: Add output event generation method to GPIOLIB and PMC Driver lakshmi.sowjanya.d
2021-09-16 21:42 ` Linus Walleij
2021-09-17 7:27 ` Uwe Kleine-König
2021-09-19 19:38 ` Linus Walleij
2021-09-19 21:21 ` Clemens Gruber
2021-09-20 7:14 ` Uwe Kleine-König
2021-08-24 16:47 ` [RFC PATCH v1 08/20] kernel: time: Add system time to system counter translation lakshmi.sowjanya.d
2021-09-16 21:48 ` Linus Walleij
2021-08-24 16:47 ` [RFC PATCH v1 09/20] arch: x86: Add TSC to ART translation lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 10/20] tools: gpio: Add GPIO output generation user application lakshmi.sowjanya.d
2021-09-16 21:52 ` Linus Walleij
2021-08-24 16:47 ` [RFC PATCH v1 11/20] gpio: Add event count interface to gpiolib lakshmi.sowjanya.d
2021-09-22 9:53 ` Bartosz Golaszewski
2021-08-24 16:47 ` [RFC PATCH v1 12/20] gpio: Add event count to Intel(R) PMC Timed I/O driver lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 13/20] tools: gpio: Add event count capability to event monitor application lakshmi.sowjanya.d
2021-09-16 21:57 ` Linus Walleij
2021-08-24 16:47 ` [RFC PATCH v1 14/20] arch/x86: Add ART nanosecond to ART conversion lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 15/20] pwm: Add capability for PWM Driver managed state lakshmi.sowjanya.d
2021-09-16 22:00 ` Linus Walleij
2021-08-24 16:47 ` [RFC PATCH v1 16/20] gpio: Add PWM capabilities to Intel(R) PMC TIO driver lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 17/20] pwm: Add second alignment to the core PWM interface lakshmi.sowjanya.d
2021-08-24 16:47 ` [RFC PATCH v1 18/20] gpio: Add PWM alignment support to the Intel(R) PMC Timed I/O driver lakshmi.sowjanya.d
2021-08-24 16:48 ` [RFC PATCH v1 19/20] gpio: Add GPIO monitor line to Intel(R) Timed I/O Driver lakshmi.sowjanya.d
2021-08-24 16:48 ` [RFC PATCH v1 20/20] tools: gpio: Add PWM monitor application lakshmi.sowjanya.d
2021-09-16 21:21 ` [RFC PATCH v1 00/20] Review Request: Add support for Intel PMC Linus Walleij
2021-10-11 21:14 ` Dipen Patel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMpxmJWeZP-f-3BoWwX7PkWNZySn5RP=rc4cVyLEwYmSb6if+w@mail.gmail.com' \
--to=bgolaszewski@baylibre.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bala.senthil@intel.com \
--cc=lakshmi.sowjanya.d@intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgross@linux.intel.com \
--cc=tamal.saha@intel.com \
--cc=warthog618@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).