linux-kernel - Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire

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/  |