linux-kernel - Re: [PATCH v5 3/4] clk: introduce the common clock 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: <20120305073836.GU3852@pengutronix.de>
Date:	Mon, 5 Mar 2012 08:38:36 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	"Turquette, Mike" <mturquette@...com>
Cc:	Andrew Lunn <andrew@...n.ch>, Paul Walmsley <paul@...an.com>,
	linaro-dev@...ts.linaro.org,
	Linus Walleij <linus.walleij@...ricsson.com>,
	patches@...aro.org, Stephen Boyd <sboyd@...eaurora.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Magnus Damm <magnus.damm@...il.com>,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Richard Zhao <richard.zhao@...aro.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Deepak Saxena <dsaxena@...aro.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Shawn Guo <shawn.guo@...escale.com>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Arnd Bergman <arnd.bergmann@...aro.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 3/4] clk: introduce the common clock framework

On Sun, Mar 04, 2012 at 04:12:21PM -0800, Turquette, Mike wrote:
> >>
> >> I believe this patch already does what you suggest, but I might be
> >> missing your point.
> >
> > In include/linux/clk-private.h you expose struct clk outside the core.
> > This has to be done to make static initializers possible. There is a big
> > warning in this file that it must not be included from files implementing
> > struct clk_ops. You can simply avoid this warning by declaring struct clk
> > with only a single member:
> >
> > include/linux/clk.h:
> >
> > struct clk {
> >        struct clk_internal *internal;
> > };
> >
> > This way everybody knows struct clk (thus can embed it in their static
> > initializers), but doesn't know anything about the internal members. Now
> > in drivers/clk/clk.c you declare struct clk_internal exactly like struct
> > clk was declared before:
> >
> > struct clk_internal {
> >        const char              *name;
> >        const struct clk_ops    *ops;
> >        struct clk_hw           *hw;
> >        struct clk              *parent;
> >        char                    **parent_names;
> >        struct clk              **parents;
> >        u8                      num_parents;
> >        unsigned long           rate;
> >        unsigned long           flags;
> >        unsigned int            enable_count;
> >        unsigned int            prepare_count;
> >        struct hlist_head       children;
> >        struct hlist_node       child_node;
> >        unsigned int            notifier_count;
> > #ifdef CONFIG_COMMON_CLK_DEBUG
> >        struct dentry           *dentry;
> > #endif
> > };
> >
> > An instance of struct clk_internal will be allocated in
> > __clk_init/clk_register. Now the private data stays completely inside
> > the core and noone can abuse it.
> 
> Hi Sascha,
> 
> I see the disconnect here.  For OMAP (and possibly other platforms) at
> least some clock data is necessary during early boot, before the
> regular allocation methods are available (timers for instance).

We had this problem on i.MX aswell. It turned out that the timer clock
is the only clock that is needed so early. We solved this by moving the
clock init to the system timer init function.

> Due
> to this my idea of static initialization was to take care of
> everything that would normally require an allocator, which includes
> the internals of struct clk; thus exposing struct clk is useful here
> as you can still use the clock framework during very early boot.  Your
> method above doesn't satisfy this requirement.  I'm not sure what the
> purpose would be of statically allocating your version of struct clk,
> which will ultimately need to allocate memory for the clock internals
> anyways.  Can you elaborate the benefit of this approach over just
> using the clk_foo_register functions?

As said the benefit is that you do not have to expose the internal
layout of struct clk outside the clock framework. Note that in the
file you referenced here:

http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/clock44xx_data.c;h=7f833a7b2dca84a52c2bd1e7c8d9cfe560771258;hb=v3.3-rc5-clkv5-omap#l205

You violate what you have in a comment above clk-private.h:

/* __clk_init is only exposed via clk-private.h and is intended for use with
 * very large numbers of clocks that need to be statically initialized. It is
 * a layering violation to include clk-private.h from any code which implements
 * a clock's .ops; as such any statically initialized clock data MUST be in
 * separate C file from the logic that implements it's operations.
 */

Well, the file is work in progress, you probably fix this before sending
it out, but I bet people will include clk-private.h and nobody else
notices it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/