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] [day] [month] [year] [list]
Date:	Thu, 11 Jul 2013 11:30:07 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nick Dyer <nick.dyer@...ev.co.uk>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan.Bowens@...el.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmeerw@...erw.net,
	bleung@...omium.org, olofj@...omium.org
Subject: Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface
 via sysfs

On Thu, Jul 11, 2013 at 08:41:41AM +0100, Nick Dyer wrote:
> Mark Brown wrote:
> > On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:

> >> For some operations it does. For example updating the whole chip config
> >> (which is a common thing to want to do), it would turn a couple of write
> >> operations into ~20 on recent chips.

> > Is that really happening on peformance critical paths other than initial
> > power up (which could be handled more neatly anyway).

> Well, you're right that we could probably add more API for performance
> critical stuff. But that wasn't your original question.

You probably don't need another API here - for example, if the driver
understands that the device is powered off and knows enugh about what
the device is doing to understand that it doesn't need to be running
then it could for example cache what is being written then flush in a
more optimal fashion.

> > If absoluely nobody has used the separate wakeup pin then the hardware
> > designers are wasting a pin there...  my point isn't that nobody would
> > use the reference design it's that some boards will have the separate
> > signal.

> That's entirely hypothetical, and you're wasting our time until you can
> actually point to such hardware, happy to write patches to support that
> mode of operation as well if you do.

See above - it's not just about the possibility that someone might have
done a better job with the hardware design, better power management is
just a good idea in general.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ