[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150529201745.GC17267@lukather>
Date: Fri, 29 May 2015 22:17:45 +0200
From: Maxime Ripard <maxime.ripard@...e-electrons.com>
To: Pavel Machek <pavel@....cz>
Cc: Felipe Balbi <balbi@...com>, Sebastian Reichel <sre@...nel.org>,
kernel list <linux-kernel@...r.kernel.org>,
dmitry.torokhov@...il.com, pali.rohar@...il.com, sre@...ian.org,
sre@...g0.de,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
linux-omap@...r.kernel.org, tony@...mide.com, khilman@...nel.org,
aaro.koskinen@....fi, ivo.g.dimitrov.75@...il.com,
patrikbachan@...il.com
Subject: Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen
regression on n900
On Fri, May 29, 2015 at 09:56:29PM +0200, Pavel Machek wrote:
> On Fri 2015-05-29 14:49:55, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, May 29, 2015 at 09:32:11PM +0200, Pavel Machek wrote:
> > > Fix dts to match what the Linux kernel expects. This works around
> > > touchscreen problems in 4.1 linux on Nokia n900.
> > >
> > > Signed-off-by: Pavel Machek <pavel@....cz>
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > > index 4b641c7..09089a6 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
> > > @@ -32,8 +32,8 @@ Example:
> > > touchscreen-fuzz-x = <4>;
> > > touchscreen-fuzz-y = <7>;
> > > touchscreen-fuzz-pressure = <2>;
> > > - touchscreen-max-x = <4096>;
> > > - touchscreen-max-y = <4096>;
> > > + touchscreen-size-x = <4096>;
> > > + touchscreen-size-y = <4096>;
> >
> > IMHO, the older binding needs to be supported as well. It's fine to
> > update the DTS for the new binding, but even Documentation says
> > touchscreen-max-[xy] and if the driver changed that, the driver should
> > be fixed too. Besides, it seems like this has been in tree since
> > v3.16:
>
> Agreed. In parent email, I have list of two commits that should be
> reverted.
So, if we sums things up. You introduce in some documentation example
some property, that you never document, that you still use in one
single DT, you don't even use that property in your driver, and now
that you realise you meant something else, you want the code that
actually parse the *right* property and does the right thing, that all
other DT agree (and depend on) to be reverted?
This is a joke, right?
If not, I can show you a handful of DTs that will be equally broken if
you revert the commits. Who wins?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists