linux-kernel - Re: Clock register in early init

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:	Mon, 21 May 2012 11:46:42 +0300
From:	Peter De Schrijver <pdeschrijver@...dia.com>
To:	"Turquette, Mike" <mturquette@...com>
CC:	Prashant Gaikwad <pgaikwad@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: Clock register in early init

> 
> On OMAP I think the only "gotcha" is setting up the timer.  One
> solution is to open code the register reads and the rate calculation
> in the timer code.  That is ugly... but it works.
> 
> > Which advantages do you see in dynamically allocating all this?
> >
> 
> There are many but I'll name a couple.  The most significant point is
> that we can avoid exposing the definition of struct clk if we
> dynamically allocate stuff.  One can use struct clk_hw_init to
> statically initialize data, or instead rely on direct calls to
> clk_register with a bunch of parameters.
> 

Which means if you make a mistake in specifying parents for example, it will
only fail at runtime, possibly before any console is active. With static
initialization, this will fail at compiletime. Much easier to debug.

> Another point is that copying the data at registration-time makes
> __initdata possible.  I haven't done the math yet to see if this
> really makes a difference.  However if we start doing single zImage's
> with multiple different ARM SoCs then this could recover some pages.
> 

On the other hand most clock structures are small, so there will be internal
fragmentation. Also the arrays of parent clock pointers can be shared between
different clocks. We have about 70 muxes in Tegra30 and 12 different parent
arrays.

Cheers,

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