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]
Date:	Wed, 6 May 2015 23:39:53 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc:	Mike Turquette <mturquette@...aro.org>, linux-clk@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
	Shawn Guo <shawn.guo@...aro.org>,
	ascha Hauer <kernel@...gutronix.de>,
	David Brown <davidb@...eaurora.org>,
	Daniel Walker <dwalker@...o99.com>,
	Bryan Huntsman <bryanh@...eaurora.org>,
	Tony Lindgren <tony@...mide.com>,
	Paul Walmsley <paul@...an.com>,
	Liviu Dudau <liviu.dudau@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Max Filippov <jcmvbkbc@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Barry Song <baohua@...nel.org>,
	Viresh Kumar <viresh.linux@...il.com>,
	Emilio López <emilio@...pez.com.ar>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Alexandre Courbot <gnurou@...il.com>,
	Tero Kristo <t-kristo@...com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Michal Simek <michal.simek@...inx.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	linux-doc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-mips@...ux-mips.org, patches@...nsource.wolfsonmicro.com,
	linux-rockchip@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org, spear-devel@...t.st.com,
	linux-tegra@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	linux-media@...r.kernel.org, rtc-linux@...glegroups.com
Subject: Re: [PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype

On 04/30, Boris Brezillon wrote:
> Clock rates are stored in an unsigned long field, but ->round_rate()
> (which returns a rounded rate from a requested one) returns a long
> value (errors are reported using negative error codes), which can lead
> to long overflow if the clock rate exceed 2Ghz.
> 
> Change ->round_rate() prototype to return 0 or an error code, and pass the
> requested rate as a pointer so that it can be adjusted depending on
> hardware capabilities.
> 
> Signed-off-by: Boris Brezillon <boris.brezillon@...e-electrons.com>
> Tested-by: Heiko Stuebner <heiko@...ech.de>
> Tested-by: Mikko Perttunen <mikko.perttunen@...si.fi>
> Reviewed-by: Heiko Stuebner <heiko@...ech.de>

This patch is fairly invasive, and it probably doesn't even
matter for most of these clock providers to be able to round a
rate above 2GHz. I've been trying to remove the .round_rate op
from the framework by encouraging new features via the
.determine_rate op. Sadly, we still have to do a flag day and
change all the .determine_rate ops when we want to add things.

What if we changed determine_rate ops to take a struct
clk_determine_info (or some better named structure) instead of
the current list of arguments that it currently takes? Then when
we want to make these sorts of framework wide changes we can just
throw a new member into that structure and be done.

It doesn't solve the unsigned long to int return value problem
though. We can solve that by gradually introducing a new op and
handling another case in the rounding path. If we can come up
with some good name for that new op like .decide_rate or
something then it makes things nicer in the long run. I like the
name .determine_rate though :/

The benefit of all this is that we don't have to worry about
finding the random clk providers that get added into other
subsystems and fixing them up. If drivers actually care about
this problem then they'll be fixed to use the proper op. FYI,
last time we updated the function signature of .determine_rate we
broke a couple drivers along the way.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ