Re: [PATCH 1/2] irq/irq_sim: provide irq_sim_fire_edge()

[Uwe Kleine-König]

On Mon, Dec 03, 2018 at 11:23:38AM +0100, Bartosz Golaszewski wrote:
> niedz., 2 gru 2018 o 23:20 Bartosz Golaszewski <brgl@xxxxxxxx> napisaÅ(a):
> >
> > niedz., 2 gru 2018 o 22:56 Uwe Kleine-KÃnig
> > <u.kleine-koenig@xxxxxxxxxxxxxx> 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.

Best regards
Uwe

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