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:	Tue, 26 Jul 2016 17:13:11 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Quentin Schulz <quentin.schulz@...e-electrons.com>,
	jic23@...nel.org, knaack.h@....de, lars@...afoo.de,
	pmeerw@...erw.net, wens@...e.org, lee.jones@...aro.org,
	antoine.tenart@...e-electrons.com,
	thomas.petazzoni@...e-electrons.com, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-input@...r.kernel.org
Subject: Re: [PATCH 4/5] input: touchscreen: support Allwinner SoCs'
 touchscreen

Hi,

On Mon, Jul 25, 2016 at 10:08:39AM -0700, Dmitry Torokhov wrote:
> > > > ... but your driver isn't registered yet. How does input_report and
> > > > input_sync behave in such a case?
> > > 
> > > This is explicitly allowed:
> > > 
> > > "
> > > ...
> > >  * NOTE: input_event() may be safely used right after input device was
> > >  * allocated with input_allocate_device(), even before it is registered
> > >  * with input_register_device(), but the event will not reach any of the
> > >  * input handlers. Such early invocation of input_event() may be used
> > >  * to 'seed' initial state of a switch or initial position of absolute
> > >  * axis, etc.
> > >  */
> > > "
> > 
> > Good to know. Still, it feels like it should be handled explicitly,
> > instead of relying on the fact that we only call input_event in our
> > handler and that it works that way.
> 
> Why? It is the documented property of input API and it is done so
> precisely so that you can register interrupt before registering input
> device. That is done because once registered input device is supposed to
> be fully-functional.  It does not matter for this driver but there are
> drivers out there that require interrupt handling as part of their
> "open" method.

I'm not questionning the input framework itself, and it works right
now because we all looked at that issue and found that it would work
even in the event of an early interrupt.

What I'm afraid of is that in a few weeks /monthes / years / decades,
someone will add something new in the driver without taking care of
that, and we will miss it because we won't have enough context.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ