linux-kernel - Re: [PATCH] input: eglx_ts, remove irq trigger flags

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: <20150318165003.GA11485@dtor-ws>
Date:	Wed, 18 Mar 2015 09:50:03 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Markus Pargmann <mpa@...gutronix.de>
Cc:	Philipp Zabel <p.zabel@...gutronix.de>,
	linux-kernel@...r.kernel.org, kernel@...gutronix.de,
	linux-input@...r.kernel.org
Subject: Re: [PATCH] input: eglx_ts, remove irq trigger flags

On Fri, Mar 13, 2015 at 08:14:47AM +0100, Markus Pargmann wrote:
> On Thu, Mar 12, 2015 at 09:28:13AM -0700, Dmitry Torokhov wrote:
> > On Thu, Mar 12, 2015 at 04:37:01PM +0100, Markus Pargmann wrote:
> > > Hi,
> > > 
> > > On Thu, Mar 12, 2015 at 04:18:03PM +0100, Philipp Zabel wrote:
> > > > Hi Markus,
> > > > 
> > > > Am Donnerstag, den 12.03.2015, 15:50 +0100 schrieb Markus Pargmann:
> > > > > The trigger settings for a given irq are parsed from DT. Defining them
> > > > > as flag for devm_request_threaded_irq() overwrites these settings. This
> > > > > results in wrong trigger settings for boards which have different irq
> > > > > triggers.
> > > > > 
> > > > > Signed-off-by: Markus Pargmann <mpa@...gutronix.de>
> > > > > ---
> > > > >  drivers/input/touchscreen/egalax_ts.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/input/touchscreen/egalax_ts.c b/drivers/input/touchscreen/egalax_ts.c
> > > > > index 4c56299284ef..b0e6448b743c 100644
> > > > > --- a/drivers/input/touchscreen/egalax_ts.c
> > > > > +++ b/drivers/input/touchscreen/egalax_ts.c
> > > > > @@ -218,7 +218,7 @@ static int egalax_ts_probe(struct i2c_client *client,
> > > > >  
> > > > >  	error = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> > > > >  					  egalax_ts_interrupt,
> > > > > -					  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> > > > > +					  IRQF_ONESHOT,
> > > > >  					  "egalax_ts", ts);
> > > > >  	if (error < 0) {
> > > > >  		dev_err(&client->dev, "Failed to register interrupt\n");
> > > > 
> > > > There are three device trees which have eeti,egalax_ts nodes with
> > > > interrupt flags 0:
> > > > 
> > > > arch/arm/boot/dts/imx53-tx53-x13x.dts (twice),
> > > > arch/arm/boot/dts/imx6dl-tx6u-811x.dts, and
> > > > arch/arm/boot/dts/imx6q-tx6q-1110.dts.
> > > > 
> > > > Will these still work after this change?
> > > 
> > > Oh right, thanks, these should be fixed as well.
> > 
> > If by fixing you mean changing DTS I do not think we can do that. Maybe
> > the driver should check if there is non-empty trigger flags in the
> > interrupt description and fall back to IRQF_TRIGGER_LOW if they are
> > absent.
> 
> I think this is more of a driver/dts bug. The devicetree binding
> documentation for the egalax_ts [1] does not describe the interrupts
> flags that should be set or that the flag should be 0. Even the example
> shows the interrupt flags being '2'(trigger high-to-low edge). These
> flags are described by the interrupt-controller. The generic
> interrupt-controller bindings describe the second parameter for
> interrupts as interrupt trigger flags [2].
> 
> So I think having a '0' as second parameter in the 'interrupts' field is a
> wrong representation of the actual hardware. This of course works as
> long as the driver ignores the trigger settings from DT which is not
> specified in the bindings.

The point is that we should not break boards with existing DTS. Yes, DTS
may be wrong, not optimal, whatever, but if it used to work we need to
keep it working.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/