linux-kernel - Re: [PATCH 0/5] Clocklib: generic clocks framework

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: <200804261102.16011.david-b@pacbell.net>
Date:	Sat, 26 Apr 2008 11:02:15 -0700
From:	David Brownell <david-b@...bell.net>
To:	Dmitry <dbaryshkov@...il.com>
Cc:	"Paul Walmsley" <paul@...an.com>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org,
	"Haavard Skinnemoen" <haavard.skinnemoen@...el.com>,
	"Russell King" <rmk+lkml@....linux.org.uk>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"pHilipp Zabel" <philipp.zabel@...il.com>,
	"Pavel Machek" <pavel@....cz>, tony@...mide.com,
	hiroshi.DOYU@...ia.com
Subject: Re: [PATCH 0/5] Clocklib: generic clocks framework

On Saturday 26 April 2008, Dmitry wrote:
> > I wouldn't pretend to have a comprehensive list at this point.  But from a
> > brief look, your clk_round_rate() and clk_set_rate() implementations will
> > not work for the present OMAP clock tree.  In OMAP, many parent clocks do
> > not have the same rate as their children.
> 
> You can easily override any calculations in your clk->set_rate/clk->round_rate/
> clk->get_rate functions.

Speaking of which:  those clk_*() interfaces need to be better
specified.  Right now they're too vague to support fully portable
callers.

 - What kind of "rounding" is provided?  Using a 10 MHz target
   rate as an example, with a 48 MHz base and a binary divider:
     * "not-lower-than" would give 12 MHz (divide-by-4)
     * "not-higher-than" would give 6 MHz (divide-by-8)
     * "closest" would give 12 MHz, only 2 MHz off
   The differences can matter, depending on what the clock drives.

   Similarly, for DPLL based clocks (out = (in/DIV)*MUL) there
   can be "lowest power" goals, like "use biggest DIV that
   produces an output within <this> error bound". 

 - Does clk_set_rate() round, or does it fail when it can't set
   that exact rate?  (Would an 0.05% difference matter?)

This issue is orthogonal to whether clocklib merges or not (and
if so, when) ... except that if it does merge, then the answers
from clocklib will become the de facto answer to those questions.

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