linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	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: Sat, 29 Aug 2020 09:35:32 +0800	[thread overview]
Message-ID: <20200829013532.GA5905@sol> (raw)
In-Reply-To: <CACRpkdZroNFFsHoBHUFTUUQij7nOcPQiXP-567+fH-Xerv=L4w@mail.gmail.com>

On Fri, Aug 28, 2020 at 04:37:19PM +0200, Linus Walleij wrote:
> On Fri, Aug 28, 2020 at 12:47 AM Kent Gibson <warthog618@gmail.com> wrote:
> 
> > 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.
> 
> This is possible to do for in-kernel users, but I don't know if that makes
> sense for userspace. It is for one-offs and prototyping after all, there
> is no need (IMO) to make it overly convenient for users to implement
> all kind of weirdness in userspace unless there is a very real use case.
> 

Fair point - in fact it is the same one that made me reconsider why I
was so concerned about potentially losing an edge event in a few rare
corner cases.

Another point for this change are that it actually simplifies the kernel
code, as it takes as much code to detect and filter these cases as it
does to include them in the normal flow.

I had a play with it yesterday and the change removes two whole
functions, gpio_v2_line_config_change_validate() and 
gpio_v2_line_config_has_edge_detection() at the expense of making
debounce_update() a little more complicated. I'm happy to put together a
v6 that incorporates those changes if there aren't any strenuous
objections - we can always revert to v5.  Or I could mail the couple of
patches I've made and if they seem reasonable then I could merge them
into this set?

Cheers,
Kent.

  reply	other threads:[~2020-08-29  1:35 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
2020-08-28 14:37       ` Linus Walleij
2020-08-29  1:35         ` Kent Gibson [this message]
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=20200829013532.GA5905@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).