From: Kent Gibson <warthog618@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v8 09/20] gpiolib: cdev: support edge detection for uAPI v2
Date: Sun, 20 Sep 2020 19:23:23 +0800 [thread overview]
Message-ID: <20200920112323.GC793608@sol> (raw)
In-Reply-To: <CAHp75VcyuPYqXTk7-yBd1dR3BitXQnz1YVkD+PuJRWVOu+1ueQ@mail.gmail.com>
On Tue, Sep 15, 2020 at 01:39:41PM +0300, Andy Shevchenko wrote:
> On Wed, Sep 9, 2020 at 1:33 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Add support for edge detection to lines requested using
> > GPIO_V2_GET_LINE_IOCTL.
> >
> > The edge_detector implementation is based on the v1 lineevent
> > implementation.
>
> ...
>
[snip]
> > +
> > + /*
> > + * We may be running from a nested threaded interrupt in which case
> > + * we didn't get the timestamp from edge_irq_handler().
> > + */
>
> > + if (!line->timestamp) {
>
> Can it be positive conditional?
>
Not sure what you mean - switch the order of the if/else?
> > + le.timestamp = ktime_get_ns();
> > + if (lr->num_lines != 1)
> > + line->req_seqno = atomic_inc_return(&lr->seqno);
> > + } else {
> > + le.timestamp = line->timestamp;
> > + }
> > + line->timestamp = 0;
> > +
> > + if (line->eflags == (GPIO_V2_LINE_FLAG_EDGE_RISING |
> > + GPIO_V2_LINE_FLAG_EDGE_FALLING)) {
> > + int level = gpiod_get_value_cansleep(line->desc);
> > +
> > + if (level)
> > + /* Emit low-to-high event */
> > + le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
> > + else
> > + /* Emit high-to-low event */
> > + le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
> > + } else if (line->eflags == GPIO_V2_LINE_FLAG_EDGE_RISING) {
> > + /* Emit low-to-high event */
> > + le.id = GPIO_V2_LINE_EVENT_RISING_EDGE;
> > + } else if (line->eflags == GPIO_V2_LINE_FLAG_EDGE_FALLING) {
> > + /* Emit high-to-low event */
> > + le.id = GPIO_V2_LINE_EVENT_FALLING_EDGE;
> > + } else {
> > + return IRQ_NONE;
> > + }
> > + line->line_seqno++;
> > + le.line_seqno = line->line_seqno;
> > + le.seqno = (lr->num_lines == 1) ? le.line_seqno : line->req_seqno;
> > + le.offset = gpio_chip_hwgpio(line->desc);
> > +
> > + ret = kfifo_in_spinlocked_noirqsave(&lr->events, &le,
> > + 1, &lr->wait.lock);
> > + if (ret)
> > + wake_up_poll(&lr->wait, EPOLLIN);
> > + else
>
> > + pr_debug_ratelimited("event FIFO is full - event dropped\n");
>
> Oh, can we really avoid printf() in IRQ context?
>
Even in the IRQ thread? Would a tracepoint be preferable?
Btw, this is drawn from the v1 implmentation.
> > +
> > +static void edge_detector_stop(struct line *line)
> > +{
>
> > + if (line->irq) {
> > + free_irq(line->irq, line);
> > + line->irq = 0;
> > + }
>
> Perhaps
>
> if (!line->irq)
> return;
>
> ?
>
No - the function is extended in subsequent patches. I usually make a
note of cases like this in the commentary, but missed this one.
> > + if (!eflags)
> > + return 0;
> > +
> > + irq = gpiod_to_irq(line->desc);
> > + if (irq <= 0)
>
> > + return -ENODEV;
>
> Why shadowing actual error code?
>
Another one drawn from the v1 implementation, so not sure.
gpiod_to_irq() can potentially return EINVAL, which is definitely not
appropriate to return, or ENXIO, which is actually more appropriate??
Cheers,
Kent.
next prev parent reply other threads:[~2020-09-20 11:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-09 10:26 [PATCH v8 00/20] gpio: cdev: add uAPI v2 Kent Gibson
2020-09-09 10:26 ` [PATCH v8 01/20] gpiolib: cdev: desc_to_lineinfo should set info offset Kent Gibson
2020-09-15 10:08 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 02/20] gpiolib: cdev: replace strncpy with strscpy Kent Gibson
2020-09-15 10:11 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 03/20] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes Kent Gibson
2020-09-15 10:12 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 04/20] gpio: uapi: define uAPI v2 Kent Gibson
2020-09-15 10:06 ` Andy Shevchenko
2020-09-20 10:48 ` Kent Gibson
2020-09-09 10:26 ` [PATCH v8 05/20] gpiolib: make cdev a build option Kent Gibson
2020-09-15 10:12 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 06/20] gpiolib: add build option for CDEV v1 ABI Kent Gibson
2020-09-15 10:15 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL Kent Gibson
2020-09-15 15:29 ` Andy Shevchenko
2020-09-09 10:26 ` [PATCH v8 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL Kent Gibson
2020-09-09 10:26 ` [PATCH v8 09/20] gpiolib: cdev: support edge detection for uAPI v2 Kent Gibson
2020-09-15 10:39 ` Andy Shevchenko
2020-09-18 12:44 ` Kent Gibson
2020-09-18 14:00 ` Andy Shevchenko
2020-09-20 11:23 ` Kent Gibson [this message]
2020-09-09 10:26 ` [PATCH v8 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL Kent Gibson
2020-09-09 10:26 ` [PATCH v8 11/20] gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL Kent Gibson
2020-09-09 10:26 ` [PATCH v8 12/20] gpiolib: cdev: support setting debounce Kent Gibson
2020-09-09 10:26 ` [PATCH v8 13/20] gpio: uapi: document uAPI v1 as deprecated Kent Gibson
2020-09-09 10:26 ` [PATCH v8 14/20] tools: gpio: port lsgpio to v2 uAPI Kent Gibson
2020-09-09 10:26 ` [PATCH v8 15/20] tools: gpio: port gpio-watch " Kent Gibson
2020-09-09 10:26 ` [PATCH v8 16/20] tools: gpio: rename nlines to num_lines Kent Gibson
2020-09-09 10:26 ` [PATCH v8 17/20] tools: gpio: port gpio-hammer to v2 uAPI Kent Gibson
2020-09-09 10:26 ` [PATCH v8 18/20] tools: gpio: port gpio-event-mon " Kent Gibson
2020-09-09 10:26 ` [PATCH v8 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon Kent Gibson
2020-09-09 10:26 ` [PATCH v8 20/20] tools: gpio: add debounce support " Kent Gibson
2020-09-14 12:45 ` [PATCH v8 00/20] gpio: cdev: add uAPI v2 Bartosz Golaszewski
2020-09-14 12:47 ` Bartosz Golaszewski
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=20200920112323.GC793608@sol \
--to=warthog618@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=bgolaszewski@baylibre.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).