Re: [PATCH v6 00/20] gpio: cdev: add uAPI v2

From: Shuah Khan
Date: Tue Sep 08 2020 - 21:16:21 EST

On 9/8/20 7:09 PM, Kent Gibson wrote:
On Tue, Sep 08, 2020 at 10:04:05AM -0600, Shuah Khan wrote:
On 9/8/20 9:54 AM, Bartosz Golaszewski wrote:
On Tue, Sep 8, 2020 at 5:24 PM Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx> wrote:

On 9/4/20 7:02 AM, Bartosz Golaszewski wrote:
On Fri, Sep 4, 2020 at 2:52 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:

On Thu, Sep 03, 2020 at 04:37:50PM +0800, Kent Gibson wrote:
On Thu, Sep 03, 2020 at 10:02:04AM +0200, Bartosz Golaszewski wrote:
On Mon, Aug 31, 2020 at 5:21 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:


To me it looks good, just a couple nits here and there and some questions.

I think it's worth deciding whether we want to keep the selftests in
tools/testing/selftests/gpio/ and then maybe consider porting
gpio-mockup-chardev.c to V2 or simply outsource it entirely to

Ooops - I wasn't even aware they existed - though it had crossed my mind
that the kernel should have some selftests somewhere - I use the libgpiod
tests, from my libgpiod port, and my own Go based test suite for my testing,
as well as some smoke tests with the tools/gpio.

The libgpiod tests only cover v1 equivalent functionality, while my Go
tests cover the complete uAPI, and both v1 and v2.

It would be good for the kernel to at least have some smoke tests to
confirm basic functionality, even thorough testing is left to a
userspace library. So the existing tests should be ported to v2, though
should also retain the v1 tests if v1 is still compiled in.

I've got a v7 ready to submit that includes a couple of patches for the
gpio-mockup selftests (their primary purpose appears to be testing the
mockup module, rather than the GPIO ABI), but I now notice that the
selftests/gpio section of the tree has a different maintainer:

scripts/ 0021-selftests-gpio-port-to-GPIO-uAPI-v2.patch
Bamvor Jian Zhang <bamv2005@xxxxxxxxx> (maintainer:GPIO MOCKUP DRIVER)
Shuah Khan <shuah@xxxxxxxxxx> (maintainer:KERNEL SELFTEST FRAMEWORK)
linux-gpio@xxxxxxxxxxxxxxx (open list:GPIO MOCKUP DRIVER)
linux-kselftest@xxxxxxxxxxxxxxx (open list:KERNEL SELFTEST FRAMEWORK)
linux-kernel@xxxxxxxxxxxxxxx (open list)

Bamvor, Shuah: do you still have interest in maintaining these, or can
we update MAINTAINERS?

I maintain kselftests and gpio selftest falls under that. Please send
selftest patches to me so I can review them.

As for the gpio mock driver and test itself, you will have to wait for
Bamvor to respond.

Hi Shuah,

I've been de facto maintaining gpio-mockup for a couple years now.
Bamvor has been quite inactive as far as gpio testing goes. I think
it's fine if you ack the selftests changes.

That is fine. I can do quick review and Ack so you can take them
through gpio tree.

In fact: I don't want selftests to block getting V2 uAPI upstream so
if that'll look like it's going to take more time then I'm for merging
V2 without any changes to selftests - in the end we have tests in
user-space already.

Tests and features go through subsystem trees to avoid delays. Please
make sure the test doesn't break the default kselftest build/run.

In the future it would help if you include all the maintainers on the
patch series, so I can review the tests from the framework angle to
see if they build/run correctly.

To clarify, the patches have been submitted to the correct maintainers.
While this v6, and those before, inadvertently broke the gpio selftests
by removing code they depend on, there have been no code changes in the
selftest tree, and so nothing for you to review. The v7 of this series
restored the functions that the selftests use so that they again build
and run - still nothing for you to review.

While I had patches for the selftests available for v7, I pulled them
from the patch series as I didn't want to bother you or Bamvor with the
other patches that you wouldn't be interested in. Further, the gpio
selftests are intended to test the gpio-mockup, as evidenced by Bamvor
being their maintainer and the code itself. There have been no changes
to the mockup here, and the existing selftests remain valid without being
ported to the latest GPIO uAPI. Porting them to the latest uAPI, and then
removing the resulting dead code from tools/gpio, is a nice to have that
can wait and shouldn't block getting the uAPI changes in tree.

Thanks for the clarification.

-- Shuah