linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: Kent Gibson <warthog618@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-gpio <linux-gpio@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 08/22] gpiolib: cdev: complete the irq/thread timestamp handshake
Date: Tue, 30 Jun 2020 11:08:37 +0200	[thread overview]
Message-ID: <CAMpxmJXbp_JYg8pX6StMy3578O4MZuatDTd-Ki6ydVY8u32+fw@mail.gmail.com> (raw)
In-Reply-To: <20200625100126.GA18788@sol>

On Thu, Jun 25, 2020 at 12:01 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Jun 25, 2020 at 11:44:30AM +0200, Bartosz Golaszewski wrote:
> > On Wed, Jun 24, 2020 at 4:08 PM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Wed, Jun 24, 2020 at 04:00:42PM +0200, Bartosz Golaszewski wrote:
> > > > wt., 23 cze 2020 o 06:02 Kent Gibson <warthog618@gmail.com> napisał(a):
> [ snip ]
> > >
> > > I'm not totally sure myself, as my understanding of how interrupts are
> > > shared in the kernel is pretty sketchy, but my concern is that if we
> > > are sharing the irq then whoever we are sharing with may release the irq
> > > and we go from nested to unnested.  Or vice versa.  Not sure if that is
> > > valid, but that was my concern, and it seemed like a minor change to
> > > cover it just in case.
> > >
> >
> > It's my understanding that a shared interrupt must be explicitly
> > requested as shared by all previous users or request_irq() will fail.
> > In this case: we call request_threaded_irq() without the IRQF_SHARED
> > flag so it's never a shared interrupt. Even if someone previously
> > requested it as shared - our call will simply fail.
> >
>
> OK.  Is there a reason not to share the interrupt?
>

If nobody requested this yet, I'd say: let's not touch it. :)

In theory, we check if the line state changed so we should be fine but
in practice this sounds like a can of worms. That being said: I don't
have a reason not to do it. Just a feeling.

> > I still think that resetting the timestamp is fine because it's not
> > being set to 0 in hardirq context. We just need a different
> > explanation.
> >
>
> Or just drop it?

Yes, I think dropping this patch for now is fine.

Bart

  reply	other threads:[~2020-06-30  9:08 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  4:00 [PATCH 00/22] gpio: cdev: add uAPI V2 Kent Gibson
2020-06-23  4:00 ` [PATCH 01/22] gpiolib: move gpiolib-sysfs function declarations into their own header Kent Gibson
2020-06-24 13:34   ` Bartosz Golaszewski
2020-06-24 13:38     ` Kent Gibson
2020-06-23  4:00 ` [PATCH 02/22] gpiolib: cdev: sort includes Kent Gibson
2020-06-24 13:34   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 03/22] gpiolib: cdev: minor indentation fixes Kent Gibson
2020-06-24 13:35   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 04/22] gpiolib: cdev: refactor gpiohandle_flags_to_desc_flags Kent Gibson
2020-06-24 13:51   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 05/22] gpiolib: cdev: rename 'filep' and 'filp' to 'file' to be consistent with other use Kent Gibson
2020-06-24 13:52   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 06/22] gpiolib: cdev: rename numdescs to num_descs Kent Gibson
2020-06-24 13:53   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 07/22] gpiolib: cdev: remove pointless decrement of i Kent Gibson
2020-06-24 13:53   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 08/22] gpiolib: cdev: complete the irq/thread timestamp handshake Kent Gibson
2020-06-24 14:00   ` Bartosz Golaszewski
2020-06-24 14:08     ` Kent Gibson
2020-06-25  9:44       ` Bartosz Golaszewski
2020-06-25 10:01         ` Kent Gibson
2020-06-30  9:08           ` Bartosz Golaszewski [this message]
2020-06-23  4:00 ` [PATCH 09/22] gpiolib: cdev: rename priv to gcdev Kent Gibson
2020-06-24 14:04   ` Bartosz Golaszewski
2020-06-24 14:19     ` Kent Gibson
2020-06-24 14:20       ` Bartosz Golaszewski
2020-06-24 23:16         ` Kent Gibson
2020-06-25 10:26           ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 10/22] gpiolib: cdev: fix minor race in GET_LINEINFO_WATCH Kent Gibson
2020-06-24 14:05   ` Bartosz Golaszewski
2020-06-24 14:46   ` Andy Shevchenko
2020-06-24 15:57     ` Kent Gibson
2020-06-24 22:58       ` Kent Gibson
2020-06-25  8:44         ` Andy Shevchenko
2020-06-25  9:13           ` Kent Gibson
2020-06-25  9:23             ` Andy Shevchenko
2020-06-25  9:36               ` Kent Gibson
2020-06-23  4:00 ` [PATCH 11/22] gpiolib: cdev: remove recalculation of offset Kent Gibson
2020-06-30  8:56   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 12/22] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes Kent Gibson
2020-06-24 14:13   ` Bartosz Golaszewski
2020-06-23  4:00 ` [PATCH 13/22] gpio: uapi: define uAPI V2 Kent Gibson
2020-06-24 14:33   ` Andy Shevchenko
2020-06-24 15:40     ` Kent Gibson
2020-06-26 14:02       ` Kent Gibson
2020-06-24 14:36   ` Bartosz Golaszewski
2020-06-24 23:58     ` Kent Gibson
2020-06-23  4:00 ` [PATCH 14/22] gpiolib: make cdev a build option Kent Gibson
2020-06-29 14:25   ` Bartosz Golaszewski
2020-06-23  4:01 ` [PATCH 15/22] gpiolib: add build option for CDEV V1 ABI Kent Gibson
2020-06-29 14:26   ` Bartosz Golaszewski
2020-06-23  4:01 ` [PATCH 16/22] gpiolib: cdev: add V2 uAPI implementation to parity with V1 Kent Gibson
2020-06-23 17:44   ` Dan Carpenter
2020-06-23 23:23     ` Kent Gibson
2020-06-23  4:01 ` [PATCH 17/22] gpiolib: cdev: report edge detection in lineinfo Kent Gibson
2020-06-23  4:01 ` [PATCH 18/22] gpiolib: cdev: support setting debounce Kent Gibson
2020-06-23  4:01 ` [PATCH 19/22] gpio: uapi: document uAPI V1 as deprecated Kent Gibson
2020-06-23  4:01 ` [PATCH 20/22] tools: gpio: switch tools to V2 uAPI Kent Gibson
2020-06-23  4:01 ` [PATCH 21/22] tools: gpio: add debounce support to gpio-event-mon Kent Gibson
2020-06-23  4:01 ` [PATCH 22/22] tools: gpio: support monitoring multiple lines Kent Gibson
2020-06-30 10:43   ` 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=CAMpxmJXbp_JYg8pX6StMy3578O4MZuatDTd-Ki6ydVY8u32+fw@mail.gmail.com \
    --to=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).