linux-kernel - RE: [PATCH v5] Fix the resolution issue in ChromeOS

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]

Message-ID: <1A63A1423E772B419A9D2E882CBCF6C4020229A9@mail>
Date:	Wed, 10 Jun 2015 22:51:03 +0800
From:	"Hn Chen" <hn.chen@...dahitech.com>
To:	"Frans Klaver" <fransklaver@...il.com>
Cc:	<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<dmitry.torokhov@...il.com>
Subject: RE: [PATCH v5] Fix the resolution issue in ChromeOS

Hi, Frans,

> Alright, I was just wondering. Seems like a waste to be waiting for something that's already finished ;-). 
> There's of course a risk that times may fluctuate between firmware versions. Did you take that into account in the code? 
> Or is there a hard maximum time for these operations defined for the firmware?
Thanks for your reminding.
After I check with the firmware guy, I will change the value of delay.
What we do here is to read the data from flash and calculate their checksum and 
will cost about 6ms for 1024 bytes. So there is a delay for 10 ms per 1024 bytes.
But in some situation, the controller will change it's running frequency(like do noise immunity), 
10ms could be too margin.

Hn.chen

-----Original Message-----
From: Frans Klaver [mailto:fransklaver@...il.com] 
Sent: Tuesday, June 02, 2015 2:18 AM
To: Hn Chen
Cc: linux-input@...r.kernel.org; linux-kernel@...r.kernel.org; dmitry.torokhov@...il.com
Subject: Re: [PATCH v5] Fix the resolution issue in ChromeOS

On Tue, Jun 02, 2015 at 12:39:13AM +0800, Hn Chen wrote:
> Hi, Klaver,
> 
> Sorry for replying late and thanks for your opinion !
> 
> About the patch descrition, I will follow your suggestion and

Ok. More on this is in Documentation/SubmittingPatches.

> maybe add more commemts between codes to be easy to read.

Only where really necessary. If you do, explain _why_ you do stuff, rather than how. The how is already in the code. If how isn't clear enough, clear up the code instead.

> >Are these (and other) delay times based on datasheet values?
> The time consuming is about the computing power of WDT87xx's controller.
> The value is from the algorithm/firmware engineer of wdt87xx.
> They think it is reasonable value to wait the controller to finish the computing.

Alright, I was just wondering. Seems like a waste to be waiting for something that's already finished ;-). There's of course a risk that times may fluctuate between firmware versions. Did you take that into account in the code? Or is there a hard maximum time for these operations defined for the firmware?

> For the rest parts, I'll just follow your opinion to modify them.
> 
> Best Regards,
> hn.chen
> 

Thanks,
Frans