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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181203110654.53o3prw3qu3u2uyf@pengutronix.de>
Date:   Mon, 3 Dec 2018 12:06:54 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Bartosz Golaszewski <brgl@...ev.pl>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

On Mon, Dec 03, 2018 at 11:57:26AM +0100, Bartosz Golaszewski wrote:
> pon., 3 gru 2018 o 11:49 Uwe Kleine-König
> <u.kleine-koenig@...gutronix.de> napisał(a):
> >
> > On Mon, Dec 03, 2018 at 11:23:38AM +0100, Bartosz Golaszewski wrote:
> > > niedz., 2 gru 2018 o 23:20 Bartosz Golaszewski <brgl@...ev.pl> napisał(a):
> > > >
> > > > niedz., 2 gru 2018 o 22:56 Uwe Kleine-König
> > > > <u.kleine-koenig@...gutronix.de> napisał(a):
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Thu, Nov 29, 2018 at 07:14:45PM +0100, Bartosz Golaszewski wrote:
> > > > > > We're getting too much into details of how to handle simulated
> > > > > > interrupts and we can continue discussing it, but meanwhile I'd like
> > > > > > to address a different thing:
> > > > > >
> > > > > > Thomas, Linus: after commit fa38869b0161 ("gpiolib: Don't support irq
> > > > > > sharing for userspace") some libgpiod tests are failing because we can
> > > > > > no longer depend on reading the value of a dummy GPIO after detecting
> > > > > > an interrupt to know the edge of the interrupt. While these interrupts
> > > > > > are triggered from debugfs and debugfs is not required to maintain
> > > > > > compatibility, I thing having a working test suite for the GPIO
> > > > > > subsystem and uAPI is worth applying these two patches and also the
> > > > > > previous one[1].
> > > > > >
> > > > > > Can we have them applied for 4.20 or are there any objections?
> > > > >
> > > > > Just for the record: I objected the patch, Bartosz agrees to discuss
> > > > > further and but because this is too much detail the patch should now be
> > > > > applied anyhow to fix the test suite of an external project. This seems
> > > > > wrong to me.
> > > > >
> > > >
> > > > Just to look at it from a different perspective: we have a project
> > > > whose tests rely on a behavior that was changed by Uwe's patch. While
> > > > the patch is fine, we need to find a correct way of testing the GPIO
> > > > user API. This may take a long time. In order to not break the tests
> > > > of an external project in 4.20 I propose to patch the interrupt
> > > > simulator (a component only used for testing) for now and to revisit
> > > > it later without time pressure.
> > > >
> > > > Best regards,
> > > > Bartosz
> > >
> > > In fact after re-reading this conversation I'm still not sure what
> > > your objection is exactly. You're proposing a solution that may well
> > > be nicely engineered but it's specific to your gpio-simulator.
> > > Meanwhile I'm trying to provide a more generalized API for more
> > > testing modules to use.
> >
> > I think you're generalizing something that won't find any user apart
> > from your mockup driver. So I'd say the generalisation is wrong and the
> > added code could better live in the mockup driver directly.
> >
> 
> It used to live in the gpio-mockup driver and I generalized it
> precisely because there was another driver - iio evgen - which was
> doing basically the same thing. While I don't know if there'll be more
> users (I'd guess it would be useful for testing purposes of other
> subsystems) having the same functionality implemented once is better
> than twice.

The iio testing driver only needs the trigger and relies on an irq that
then calls the registerd handler. The iio driver doesn't need to tune
the edge sensitivity though and if your mockup driver just only calls
the fire routine if the configured sensitivity justifies that,
everything should work as expected.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ