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:   Wed, 9 Sep 2020 09:09:00 +0800
From:   Kent Gibson <warthog618@gmail.com>
To:     Shuah Khan <skhan@linuxfoundation.org>
Cc:     Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Bamvor Jian Zhang <bamv2005@gmail.com>,
        Shuah Khan <shuah@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-gpio <linux-gpio@vger.kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH v6 00/20] gpio: cdev: add uAPI v2
Message-ID: <20200909010900.GA8496@sol>
References: <20200831032006.1019978-1-warthog618@gmail.com>
 <CAMpxmJUETJgmxzWzHumOVr+vWFQ27P71MtcdSdf_=jvtrSfRPg@mail.gmail.com>
 <20200903083750.GA17445@sol>
 <20200904125250.GA323947@sol>
 <CAMpxmJWVZ8Bf1gPibvbk=E5XNvQ_i76E430MMhUWwE1ACoPTQg@mail.gmail.com>
 <9db62b42-9a1e-0264-e88c-e636004cb629@linuxfoundation.org>
 <CAMpxmJVbujnp+Z0b3utDsGmhUgCbhydorOo-9e-=gVctT55NAg@mail.gmail.com>
 <af4036b7-72b7-16f3-92de-4976b49d857e@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <af4036b7-72b7-16f3-92de-4976b49d857e@linuxfoundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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@linuxfoundation.org> wrote:
> > > 
> > > On 9/4/20 7:02 AM, Bartosz Golaszewski wrote:
> > > > On Fri, Sep 4, 2020 at 2:52 PM Kent Gibson <warthog618@gmail.com> 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@gmail.com> wrote:
> > > > > > > > 
> > > > > [snip]
> > > > > > > 
> > > > > > > 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
> > > > > > > libgpiod.
> > > > > > > 
> > > > > > 
> > > > > > 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/get_maintainer.pl 0021-selftests-gpio-port-to-GPIO-uAPI-v2.patch
> > > > > Bamvor Jian Zhang <bamv2005@gmail.com> (maintainer:GPIO MOCKUP DRIVER)
> > > > > Shuah Khan <shuah@kernel.org> (maintainer:KERNEL SELFTEST FRAMEWORK)
> > > > > linux-gpio@vger.kernel.org (open list:GPIO MOCKUP DRIVER)
> > > > > linux-kselftest@vger.kernel.org (open list:KERNEL SELFTEST FRAMEWORK)
> > > > > linux-kernel@vger.kernel.org (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.

Cheers,
Kent.