linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2
Date: Fri, 28 Aug 2020 06:47:42 +0800	[thread overview]
Message-ID: <20200827224742.GA3714@sol> (raw)
In-Reply-To: <CAMpxmJXRY2wqqN3SzfJN+QTWAHYSYz4vEjLKWU82Y=PAmcm=5w@mail.gmail.com>

On Thu, Aug 27, 2020 at 06:02:03PM +0200, Bartosz Golaszewski wrote:
> On Thu, Aug 27, 2020 at 5:53 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> >
> > On Thu, Aug 27, 2020 at 4:00 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > > This patchset defines and implements a new version of the
> > > GPIO CDEV uAPI to address existing 32/64-bit alignment issues, add
> > > support for debounce, event sequence numbers, and allow for requested
> > > lines with different configurations.
> > > It provides some future proofing by adding optional configuration fields
> > > and padding reserved for future use.
> > >
> > > The series can be partitioned into three blocks; the first two patches
> > > are minor fixes that impact later patches, the next eleven contain the
> > > v2 uAPI definition and implementation, and the final seven port the GPIO
> > > tools to the v2 uAPI and extend them to use new uAPI features.
> > >
> > > The more complicated patches include their own commentary where
> > > appropriate.
> >
> > I'm ready to queue this now. Certainly any remaining snags can be
> > fixed in-tree.
> >
> > It kind of keeps in tradition with proper software projects "plan to
> > throw one away" which is what we have traditionally done several
> > times: the first Bluetooh framework was tossed, JFFS was tossed
> > for JFFS2, Video4Linux was tossed for V4L2. So let's do this.
> >
> > Anyone against? I will put it on an immutable branch and then merge
> > that in for devel.
> >
> 
> Hi Linus,
> 
> please hold it maybe for one more week - I'd love to have some more
> people take a look at the user facing header at least. Andy is usually
> very thorough in his reviews so I'm Ccing him here.
> 
> I'll too skim through the series one more time.
> 

I'd be happier with more eyeballs over it before it goes in as well.

I'm also wondering if it is worthwhile dropping the restriction on
changing edge detection configuration, that is present in
gpio_v2_line_config_change_validate() in patch 10, so long as userspace
is made aware that changing it may result in lost interrupts as we
may need to release and re-request the interrupt to effect the change.

Similarly changing debounce while edge detection is enabled, that is
disallowed in patch 12.

My policy when writing the implementation was to disallow any operation
that may have unanticiapted side-effects, and forcing userspace to
release and re-request the line(s), but that may be overly restrictive?
The particular use case I am considering is one I had been asked about -
changing a requested line from input with edge detection to output, and
vice versa. Losing interrupts isn't really an issue for this use case -
it is expected.  Yet the current implementation requires a re-request.

Cheers,
Kent.

  reply	other threads:[~2020-08-27 22:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 14:00 [PATCH v5 00/20] gpio: cdev: add uAPI v2 Kent Gibson
2020-08-27 14:00 ` [PATCH v5 01/20] gpiolib: cdev: desc_to_lineinfo should set info offset Kent Gibson
2020-08-27 14:00 ` [PATCH v5 02/20] gpiolib: cdev: replace strncpy with strscpy Kent Gibson
2020-08-27 14:00 ` [PATCH v5 03/20] gpio: uapi: define GPIO_MAX_NAME_SIZE for array sizes Kent Gibson
2020-08-27 14:00 ` [PATCH v5 04/20] gpio: uapi: define uAPI v2 Kent Gibson
2020-08-27 14:00 ` [PATCH v5 05/20] gpiolib: make cdev a build option Kent Gibson
2020-08-27 14:00 ` [PATCH v5 06/20] gpiolib: add build option for CDEV v1 ABI Kent Gibson
2020-08-27 14:00 ` [PATCH v5 07/20] gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL Kent Gibson
2020-08-27 14:00 ` [PATCH v5 08/20] gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL Kent Gibson
2020-08-27 14:00 ` [PATCH v5 09/20] gpiolib: cdev: support edge detection for uAPI v2 Kent Gibson
2020-08-27 14:00 ` [PATCH v5 10/20] gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL Kent Gibson
2020-08-27 14:00 ` [PATCH v5 11/20] gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL Kent Gibson
2020-08-27 14:00 ` [PATCH v5 12/20] gpiolib: cdev: support setting debounce Kent Gibson
2020-08-27 14:00 ` [PATCH v5 13/20] gpio: uapi: document uAPI v1 as deprecated Kent Gibson
2020-08-27 14:00 ` [PATCH v5 14/20] tools: gpio: port lsgpio to v2 uAPI Kent Gibson
2020-08-27 14:00 ` [PATCH v5 15/20] tools: gpio: port gpio-watch " Kent Gibson
2020-08-27 14:00 ` [PATCH v5 16/20] tools: gpio: rename nlines to num_lines Kent Gibson
2020-08-27 14:00 ` [PATCH v5 17/20] tools: gpio: port gpio-hammer to v2 uAPI Kent Gibson
2020-08-27 14:00 ` [PATCH v5 18/20] tools: gpio: port gpio-event-mon " Kent Gibson
2020-08-27 14:00 ` [PATCH v5 19/20] tools: gpio: add multi-line monitoring to gpio-event-mon Kent Gibson
2020-08-27 14:00 ` [PATCH v5 20/20] tools: gpio: add debounce support " Kent Gibson
2020-08-27 15:53 ` [PATCH v5 00/20] gpio: cdev: add uAPI v2 Linus Walleij
2020-08-27 16:02   ` Bartosz Golaszewski
2020-08-27 22:47     ` Kent Gibson [this message]
2020-08-28 14:37       ` Linus Walleij
2020-08-29  1:35         ` Kent Gibson
2020-09-01  9:28           ` Bartosz Golaszewski
2020-09-10 14:09             ` Andy Shevchenko
2020-09-10 14:12               ` Bartosz Golaszewski
2020-09-10 14:18                 ` Andy Shevchenko
2020-09-10 11:10     ` Andy Shevchenko
2020-09-10 11:51       ` 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=20200827224742.GA3714@sol \
    --to=warthog618@gmail.com \
    --cc=andriy.shevchenko@linux.intel.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).