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]
Message-ID: <CAMRc=Mfs_Wwm9bW121iMLrAAfuYhhekQnFRHYZBYU=Ry_dEKwg@mail.gmail.com>
Date:   Mon, 12 Nov 2018 15:14:31 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Bamvor Jian Zhang <bamv2005@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] gpio: mockup: fix indicated direction

niedz., 11 lis 2018 o 17:59 Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> napisał(a):
>
> On Fri, Nov 09, 2018 at 06:23:01PM +0100, Bartosz Golaszewski wrote:
> > pt., 9 lis 2018 o 18:03 Uwe Kleine-König
> > <u.kleine-koenig@...gutronix.de> napisał(a):
> > >
> > > Hello Bartosz,
> > >
> > > On Fri, Nov 09, 2018 at 04:24:10PM +0100, Bartosz Golaszewski wrote:
> > > > pt., 9 lis 2018 o 15:39 Uwe Kleine-König
> > > > <u.kleine-koenig@...gutronix.de> napisał(a):
> > > > > On Fri, Nov 09, 2018 at 02:53:16PM +0100, Bartosz Golaszewski wrote:
> > > > > > pt., 9 lis 2018 o 14:10 Uwe Kleine-König
> > > > > > <u.kleine-koenig@...gutronix.de> napisał(a):
> > > > > > > Which test failed exactly?
> > > > > >
> > > > > > All gpioinfo tests that check the output of this command and expect to
> > > > > > see input as line direction.
> > > > >
> > > > > This wasn't the answer I expected. The background of my question was:
> > > > > This failing test seems to expect that a given GPIO is an input. If that
> > > > > expectation already exists after the gpio is only requested, then the
> > > > > test is broken and a fix is necessary there.
> > > >
> > > > The test is only expected to work with gpio-mockup which is a dummy
> > > > testing module. I believe its behavior should be as deterministic as
> > > > possible to the point where newly created chips always have the same
> > > > direction.
> > >
> > > Given that the initial direction of a GPIO isn't fixed in my eyes the
> > > test should be able to cope with both possibilities. I'd say it's a bug
> > > in the test if it doesn't.
> > >
> >
> > As I said before: it is and should be fixed in this specific case.
> > This isn't real hardware.
>
> Not sure if we agree here yet. What do you want to fix? The driver or
> the test?
>
> In my eyes test driven development is great. But if something breaks
> because the test is wrong, please don't "fix" the system to repair the
> test, but modify the test to be able to handle reality.
>

No, we don't have an agreement. You think I should fix the test, I
think the dummy driver should continue behaving like before.

Given that there's no real hardware behind, the direction of newly
created dummy lines has always been deterministic - input. Certain
tests have been relying on it. I want to keep on doing it. There's no
harm. It's not broken logic as the very purpose of this module is to
allow for easy testing of the UAPI.

So unless something *else* is wrong with this patch, I intend to push
it upstream.

Best regards,
Bartosz Golaszewski

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ