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-next>] [day] [month] [year] [list]

Message-ID: <54E34786.1010102@ti.com>
Date:	Tue, 17 Feb 2015 15:52:06 +0200
From:	Roger Quadros <rogerq@...com>
To:	Robert Abel <rabel@...-ec.uni-bielefeld.de>
CC:	<khilman@...prootsystems.com>, Tony Lindgren <tony@...mide.com>,
	<linux@....linux.org.uk>, <linux-omap@...r.kernel.org>,
	Linux Kernel Maling List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] ARM OMAP2+ GPMC: always program GPMCFCLKDIVIDER

On 17/02/15 15:34, Robert Abel wrote:
> Hi Roger,
> 
> On Tue, Feb 17, 2015 at 9:12 AM, Roger Quadros <rogerq@...com <mailto:rogerq@...com>> wrote:
> 
>     Can you use the following wording from TRM instead?
> 
>     as per am335x TRM (spruh73i.pdf), section 7.1.3.3.8.3.2
> 
>     The WAITMONITORINGTIME is expressed as a number of GPMC_CLK clock cycles,
>     even though the access is defined as asynchronous, and no GPMC_CLK clock
>     is provided to the external device. Still, GPMCFCLKDIVIDER is used as a divider
>     for the GPMC clock, so it must be programmed to define the
>     correct WAITMONITORINGTIME delay.
> 
> 
> Verbatim? Sure can. Gonna do that with a rebase to 3.19, I guess.
>  
> 
>     Instead of this can we explicitly set the GPMC_CLK divider to 1 and hence
>     corresponding divider bits to 0 in the asynchronous case?
>     This is because the previously calculated "div" depends on synchronous clock which
>     might not be properly initialized for asynchronous devices.
> 
> 
> No, we shouldn't. If WAITREADMONITORING and/or WAITWRITEMONITORING is enabled, sync_clk must be set in order to use WAITMONITORINGTIME correctly. If it's not explicitly set, it's set to 0, which yields div 1 anyways.
> The reason being that a fixed divider of 1 will limit a user's ability to prolong the #WAIT-deassert --> *access delay for no good reason. If working with a slow device, this will inconvenience users.

nobody stops the DT binding from specifying a large enough "gpmc,wait-monitoring-ns" value.
The driver must use that to scale the GPMC_CLK if it doesn't fit in the GPMC_FCLK.
This feature can come separately though. So for now I was suggesting to set the divisor to 1.

What I'm stressing on is that there shouldn't be any dependency on "gpmc,sync-clk-ps" for
asynchronous devices. It also becomes easier to specify the wait-monitoring-ns as we don't need
to cross reference with "sync-clk-ps".

>  
> 
>     AFAIK t->sync_clk is always 0 for asynchronous devices and gpmc_calc_divider(0)
>     will return 1 and your patch will work but still we shouldn't depend on sync_clk for
>     asynchronous devices so let's set this explicitly.
> 
>  
> See above. Hardware depends on divider, divider is set by sync_clk, so we shouldn't limit what a user can program in DT.
> Having said that, I'm not aware that sync_clk is always 0 for async devices. The code always parses it and sets the appropriate field in gpmc_t, which is passed to gpmc_cs_set_timings.
> Now, there is generally a lack of checking for optional/required DT properties, so I didn't add extra checking.

AFAIK "gpmc,sync-clk-ps" is not specified for asynchronous devices so it defaults to 0
in the driver.

cheers,
-roger
--
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/