linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Kent Gibson <warthog618@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v5 0/7] gpiolib: add an ioctl() for monitoring line status changes
Date: Thu, 23 Jan 2020 12:37:26 +0100	[thread overview]
Message-ID: <20200123113726.GA980445@kroah.com> (raw)
In-Reply-To: <CAMRc=Mc80hudqxHMp87_Ro+k1YQNeo=FxYD0oZy_g7P=Z2w-Zw@mail.gmail.com>

On Thu, Jan 23, 2020 at 11:15:05AM +0100, Bartosz Golaszewski wrote:
> wt., 14 sty 2020 o 08:44 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
> >
> > czw., 9 sty 2020 o 12:50 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
> > >
> > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > >
> > > When discussing the recent user-space changes with Kent and while working
> > > on dbus API for libgpiod I noticed that we really don't have any way of
> > > keeping the line info synchronized between the kernel and user-space
> > > processes. We can of course periodically re-read the line information or
> > > even do it every time we want to read a property but this isn't optimal.
> > >
> > > This series adds a new ioctl() that allows user-space to set up a watch on
> > > the GPIO chardev file-descriptor which can then be polled for events
> > > emitted by the kernel when the line is requested, released or its status
> > > changed. This of course doesn't require the line to be requested. Multiple
> > > user-space processes can watch the same lines.
> > >
> > > This series also includes a variety of minor tweaks & fixes for problems
> > > discovered during development. For instance it addresses a race-condition
> > > in current line event fifo.
> > >
> > > First two patches add new helpers to kfifo, that are used in the later
> > > parts of the series.
> > >
> > > v1: https://lkml.org/lkml/2019/11/27/327
> > >
> > > v1 -> v2:
> > > - rework the main patch of the series: re-use the existing file-descriptor
> > >   associated with an open character device
> > > - add a patch adding a debug message when the line event kfifo is full and
> > >   we're discarding another event
> > > - rework the locking mechanism for lineevent kfifo: reuse the spinlock
> > >   from the waitqueue structure
> > > - other minor changes
> > >
> > > v2 -> v3:
> > > - added patches providing new implementation for some kfifo macros
> > > - fixed a regression in the patch reworking the line event fifo: reading
> > >   multiple events is now still possible
> > > - reworked the structure for new ioctl: it's now padded such that there
> > >   be no alignment issues if running a 64-bit kernel on 32-bit userspace
> > > - fixed a bug where one process could disable the status watch of another
> > > - use kstrtoul() instead of atoi() in gpio-watch for string validation
> > >
> > > v3 -> v4:
> > > - removed a binary file checked in by mistake
> > > - drop __func__ from debug messages
> > > - restructure the code in the notifier call
> > > - add comments about the alignment of the new uAPI structure
> > > - remove a stray new line that doesn't belong in this series
> > > - tested the series on 32-bit user-space with 64-bit kernel
> > >
> > > v4 -> v5:
> > > - dropped patches already merged upstream
> > > - collected review tags
> > >
> > > Bartosz Golaszewski (7):
> > >   kfifo: provide noirqsave variants of spinlocked in and out helpers
> > >   kfifo: provide kfifo_is_empty_spinlocked()
> > >   gpiolib: rework the locking mechanism for lineevent kfifo
> > >   gpiolib: emit a debug message when adding events to a full kfifo
> > >   gpiolib: provide a dedicated function for setting lineinfo
> > >   gpiolib: add new ioctl() for monitoring changes in line info
> > >   tools: gpio: implement gpio-watch
> >
> > Hi Andrew,
> >
> > could you Ack the first two patches in this series if you're fine with
> > them? The code they modify lives in lib/ and doesn't have an assigned
> > maintainer, so I've been told to Cc you on this series. It would be
> > great if we could get it in for v5.6 merge window.
> >
> > Best regards,
> > Bartosz Golaszewski
> 
> Gentle ping.
> 
> Greg: could you maybe ack the kfifo patches so that we can get this in for v5.6?

I am not the kfifo maintainer :(

  reply	other threads:[~2020-01-23 11:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 11:50 [PATCH v5 0/7] gpiolib: add an ioctl() for monitoring line status changes Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 1/7] kfifo: provide noirqsave variants of spinlocked in and out helpers Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 2/7] kfifo: provide kfifo_is_empty_spinlocked() Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 3/7] gpiolib: rework the locking mechanism for lineevent kfifo Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 4/7] gpiolib: emit a debug message when adding events to a full kfifo Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 5/7] gpiolib: provide a dedicated function for setting lineinfo Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 6/7] gpiolib: add new ioctl() for monitoring changes in line info Bartosz Golaszewski
2020-01-09 11:50 ` [PATCH v5 7/7] tools: gpio: implement gpio-watch Bartosz Golaszewski
2020-01-14  7:44 ` [PATCH v5 0/7] gpiolib: add an ioctl() for monitoring line status changes Bartosz Golaszewski
2020-01-23 10:15   ` Bartosz Golaszewski
2020-01-23 11:37     ` Greg Kroah-Hartman [this message]
2020-01-23 14:06       ` 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=20200123113726.GA980445@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=brgl@bgdev.pl \
    --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).