linux-kernel - Re: [PATCH 1/2] Add a common struct clk

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:	Tue, 18 Jan 2011 18:23:19 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	Jeremy Kerr <jeremy.kerr@...onical.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Ben Herrenchmidt <benh@...nel.crashing.org>,
	Uwe Kleine-K?nig <u.kleine-koenig@...gutronix.de>
Subject: Re: [PATCH 1/2] Add a common struct clk

On Tue, Jan 18, 2011 at 10:21:28AM +0100, Sascha Hauer wrote:
> On Tue, Jan 18, 2011 at 05:44:45PM +0900, Paul Mundt wrote:
> > Do you guys even bother to grep the kernel for users of the API before
> > coming up with arbitrary policy?
> 
> Actually I did bother to grep the kernel and I came up with these
> results:
> 
> drivers/video/omap2/dss/dss.c:219:      dpll4_ck_rate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
> drivers/video/omap2/dss/dss.c:312:      prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
> drivers/video/omap2/dss/dss.c:325:              prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
> drivers/video/omap2/dss/dss.c:344:              prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
> drivers/video/omap2/dss/dss.c:359:              return clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
> drivers/video/sh_mobile_hdmi.c:716:     else if (clk_get_parent(hdmi->hdmi_clk))
> drivers/video/sh_mobile_hdmi.c:717:             *parent_rate = clk_get_rate(clk_get_parent(hdmi->hdmi_clk));
> drivers/video/sh_mobile_hdmi.c:1089:    if (parent_rate && clk_get_parent(hdmi->hdmi_clk)) {
> drivers/video/sh_mobile_hdmi.c:1090:            ret = clk_set_rate(clk_get_parent(hdmi->hdmi_clk), parent_rate);
> drivers/usb/host/ehci-omap.c:405:                       ret = clk_set_parent(omap->utmi_p1_fck,
> drivers/usb/host/ehci-omap.c:435:                       ret = clk_set_parent(omap->utmi_p2_fck,
> 
Then I recommend you grep harder. There are more drivers than the ones
that simply live in drivers/.

> > There are plenty of cases where clocks are allocated dynamically by
> > driver code that in turn can be set up as a parent for other dynamically
> > allocated clocks. This has not a damn thing to do with platform code and
> > everything to do with the clock circuitry of the device or IP block in
> > question.
> 
> The majority of users do not use clk_{get,set}_parent at all. And it's
> really questionable whether drivers should know anything about the
> layout of the clock tree. I'm pretty sure that these are the code pieces
> where there will be a if_soc_rev(x) around it once the next incarnation
> of a SoC comes out.
> 
It's not questionable in the least, you're simply dealing with cases
where you personally haven't had a need to do so and are attempting to
project that as a policy. I'm getting pretty tired of this.

We have many IP blocks that can use external clocks or drive their own
clock circuitry, in which case the internal clocks are parented by a
parent clock that is likewise also dynamically created. Your lack of
imagination is really not my concern, and again, this has nothing to do
with the SoC.
--
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/