linux-kernel - Re: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER

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: <54E24E67.9060806@cit-ec.uni-bielefeld.de>
Date:	Mon, 16 Feb 2015 21:09:11 +0100
From:	Robert Abel <rabel@...-ec.uni-bielefeld.de>
To:	Tony Lindgren <tony@...mide.com>
CC:	khilman@...prootsystems.com, linux@....linux.org.uk,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER

Hi Tony,

On 16 Feb 2015 18:10, Tony Lindgren wrote:
> * Robert ABEL <rabel@...-ec.uni-bielefeld.de> [150216 07:52]:
>> GPMC uses GPMCFCLKDIVIDER during synchronous as well as asynchronous accesses
>> in conjunction with WAITMONITORINGTIME. Thus, it's wrong to only program it for
>> synchronous accesses. Remove the conditional.
> Do you have some test case that gets fixed by this? Or does this
> fix some regression?
>
> The reason why I'm asking is that AFAIK we've had async access
> working all along?
Maybe to clarify: This is only affects asynchronous accesses with 
WAITREADMONITORING and/or WAITWRITEMONITORING enabled. Regular 
asynchronous accesses without WAIT pin monitoring were never affected to 
begin with and are not affected by this change.

I don't have an off-hand test case and seeing as the current 
implementation is faulty, it's probable nobody actively uses this 
feature. Cf. OMAP35xx TRM (SPRUF98X) pp. 1103. Basically, 
WAITMONITORINGTIME extends the number of cycles from the end of WAIT 
asserted to when the data is provided/sampled and the read/write access 
(should) take place. While this behavior is esoteric, it's not a reason 
not to fix this oversight.

Regards,

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