linux-kernel - Re: [PATCH] fix n900 dts file to work around 4.1 touchscreen regression on n900

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]

Date:	Fri, 29 May 2015 13:48:47 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Felipe Balbi <balbi@...com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Sebastian Reichel <sre@...nel.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	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 10:34:56PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > 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
> > > 
> > > not Pali, Sebastian.
> > > 
> > > > actually parse the *right* property and does the right thing, that all
> > > > other DT agree (and depend on) to be reverted?
> > > 
> > > We shouldn't revert, that I agree. But both properties should be parsed.
> > 
> > No. If the property is wrong, and nobody parsed it, I do not see any reason to
> > start now.
> 
> Agreed.
> 
> But that's not what I'm asking. See a changelog of
> 3eea8b5d68c801fec788b411582b803463834752 and compare it with what it
> actually does.
> 
> It is buggy. If fuzz is specified but maximum is not, it overwites
> maximum with zero.

Yes.

> 
> Plus it introduces new failure "if (!test_bit(axis, dev->absbit))".

That is not a new failure. It actually warns users that they trying to
specify in DT something that will be ignored by the kernel (because
without that absbit kernel will ignore all requests to that event code).

> 
> Plus it fails to distinguish between "value not specified in the dt"
> and "zero is specified in the dt".

Yes. I am not sure if we should care and support all permutations (ah, I
pre-setup fuzz in the driver, but override max on X, and I pre-setup
max on X, but take fuzz from DT). Maybe we should simply document that
specifying one parameter for an axis will change the rest of them to be
0. Not sure though...

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/