Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 29 Aug 2020 09:35:32 +0800
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
Message-ID: <20200829013532.GA5905@sol>
References: <20200827140020.159627-1-warthog618@gmail.com>
 <CACRpkdZZMbfpKy4gcfAzNq53LkYLcL9wm3Qtzyj_K8vkUW9RfQ@mail.gmail.com>
 <CAMpxmJXRY2wqqN3SzfJN+QTWAHYSYz4vEjLKWU82Y=PAmcm=5w@mail.gmail.com>
 <20200827224742.GA3714@sol>
 <CACRpkdZroNFFsHoBHUFTUUQij7nOcPQiXP-567+fH-Xerv=L4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACRpkdZroNFFsHoBHUFTUUQij7nOcPQiXP-567+fH-Xerv=L4w@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.