linux-kernel - Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Aug 2020 17:53:28 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Kent Gibson <warthog618@...il.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2

On Thu, Aug 27, 2020 at 4:00 PM Kent Gibson <warthog618@...il.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.

Yours,
Linus Walleij