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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 25 Apr 2012 22:26:05 +0530
From:	anish kumar <anish198519851985@...il.com>
To:	NeilBrown <neilb@...e.de>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: twl4030 power button: don't lose presses on
 resume

On Wed, 2012-04-25 at 15:26 +1000, NeilBrown wrote:
> On Tue, 24 Apr 2012 22:09:19 -0700 Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> 
> > Hi Neil,
> > 
> > On Wed, Apr 25, 2012 at 12:21:39PM +1000, NeilBrown wrote:
> > > 
> > > If we press and release the power button before the press interrupt is
> > > handled - as can happen on resume - we lose the press event so the
> > > release event is ignored and we don't know what happened to cause the
> > > wakeup.
I didn't understand this.If power button is waking up the device then
obviously power button interrupt handler is called right?If yes then how
can we lose the press event?Is user space not ready to take the event?
May be I didn't understand it properly.Can you kindly explain?
> > 
> > What kind of latency do you observe?
> 
> When I have debugging enabled, hundreds of milliseconds.
> 
> When I don't have debugging enabled ... it doesn't tell me, but I'm fairly
> sure it is several tens of milliseconds and the button press can be quicker
> than that.
> 
> If it will help I can try to instrument the driver and get some timings.
> 
> > 
> > > 
> > > So make sure that each interrupt handled does generate an event.
> > > Because twl4030 queues interrupt events we will see two interrupts
> > > for a press-release even if we handle the first one later.  This means
> > > that such a sequence will be reported as two button presses.  This
> > > is unfortunate but is better than no button presses.
> > > Possibly we could set the PENDDIS_MASK to disable queuing of
> > > interrupts, but that might adversely affect other interrupt sources.
> > >
> > 
> > It looks like we'd have to modify every driver to ensure consistent
> > behavior as we do not have any guarantees on how long resume takes.
> > Maybe this is something that input core needs to implement?
> 
> Well if every driver is buggy....
> 
> I don't see how this could be implemented in the input core.  And even if it
> was, you'd probably need to change each driver to interact with this new
> functionality which would be much the same work as changing them to work with
> the current functionality....
> But maybe I have no imagination - if you can suggest a way that the input core
> could support this without changing the drivers, I'm happy to try it out.
> 
> Thanks,
> NeilBrown


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ