linux-kernel - Re: [PATCH F 06/12] OMAP2/3 clock: every clock must have a clkdm

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, 3 Feb 2009 02:27:00 -0700 (MST)
From:	Paul Walmsley <paul@...an.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH F 06/12] OMAP2/3 clock: every clock must have a clkdm

Hello Russell,

On Sat, 31 Jan 2009, Russell King - ARM Linux wrote:

> On Wed, Jan 28, 2009 at 12:35:15PM -0700, Paul Walmsley wrote:
> > Every OMAP2/3 clock must now have an assigned clockdomain, so we can
> > remove the checks from clk_enable()/clk_disable().  Instead, verify
> > that the clockdomain is present only at clock init time via the
> > arch_clock clk_register() hook.
> 
> I don't see the point of requiring all clocks to have a clockdomain field.

For physical clocks, the idea is to match the OMAP2/3 hardware, in which 
nearly every clock is associated with a clockdomain.  The point for 
virtual clocks is to discourage the use of virtual clocks.

> Given that we have virtual clocks, it is quite reasonable for some clocks
> not to have a clock domain associated with them.

Virtual clocks should soon be eliminated from the OMAP clock tree.  ( 
"Virtual clocks" is here used to refer a clock that does not have a 
referent in the hardware; the usage of the term in the code is loose.)  
So far as I know, all of the OMAP virtual clocks have either turned out to 
be superfluous (and prone to spinlock recursion bugs), or to be better 
implemented outside of the clock framework (such as the virtual OPP 
clocks).  We've eliminated the former.  We should be able to eliminate the 
latter in a few months.

Only physical hardware clocks will then be left in the clock tree.  For 
OMAP2/3, it makes sense to keep those grouped into clockdomains, since 
that is how they are implemented in the hardware.

So I'd recommend keeping this requirement.

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