linux-kernel - Re: [PATCH 0/3] clk: divider: three exactness fixes (and a rant)

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: <54FE215D.7090804@codeaurora.org>
Date:	Mon, 09 Mar 2015 15:40:29 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Mike Turquette <mturquette@...aro.org>
CC:	Philipp Zabel <p.zabel@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Sören Brinkmann <soren.brinkmann@...inx.com>,
	kernel@...gutronix.de
Subject: Re: [PATCH 0/3] clk: divider: three exactness fixes (and a rant)

On 03/09/15 14:58, Uwe Kleine-König wrote:
>
> If you see
>
> 	round_rate(110) = 108
>
> it would be fortunate to know if you get 108 because the next available
> greater rate is > 112 or because the implementation rounds down always
> (which would mean that 111 is possible, too). For the "easy" consumers
> this probably doesn't matter much, but if you do things that affects
> a considerable part of the clock tree, you really want to know more
> about the behaviour of round_rate to effectively work with its results.
>
> So yes, please let us pick ceiling for round_rate (i.e. a fixed policy
> for all clks) and then it should even be possible to make
> clk_set_rate_range a generic function that doesn't need the min and max
> members in the clk struct and the respective parameters to
> determine_rate.
>
> What should a clock that can only provide 100 Hz return on
>
> 	clk_round_rate(clk, 60);
>
> ? 0? -ESOMETHING (for SOMETHING = ...?)?
>

Do you have any real world use cases, or is this just all theoretical?
At least in Philipp's panel case we can discuss how to make an API that
works properly. These other examples are either completely theoretical
or taken out of context and so it's unclear how they matter in practice.

Ideally I'd like an API to exist that doesn't require going back and
forth with the framework (i.e. it's "atomic" and doesn't require calling
clk_round_rate() in a loop) and that allows consumers to properly
express what they want. Right now we have a way to say min/max and a
typical rate is in the works. If we need to declare some sort of clock
provider rounding policy then we've failed to provide an API that
properly expresses all the requirements that the consumer has. It
probably means we're missing some key parameter that consumers know but
we don't accept. Maybe some more concrete examples will help clarify
what this is.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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