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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201101111827.12291.jeremy.kerr@canonical.com>
Date:	Tue, 11 Jan 2011 18:27:11 +0800
From:	Jeremy Kerr <jeremy.kerr@...onical.com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	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

Hi Sascha,

> The i.MX clk implementation disables the old parent if clk is enabled
> and enables the new parent if clk is enabled (modulo bugs). Shouldn't
> we do this here aswell?

Sounds reasonable, yes.

> I thought about returning -EBUSY if clk_set_parent is called for an
> enabled clk, but this way we could never reparent the cpu clock which I
> think is done in the Freescale BSP for power saving.

I think that the possibility for changing the parent really depends on the 
implementation; in some cases we may want to disallow it, in others it might 
be fine.

Related: do we really need globally-accessible clk_{get,set}_parent in the clk 
API? For cases where we need to set the parent, we probably need details about 
the platform clock configuration (eg, which clocks are possible parents). In 
this case, we could just call into the clock driver directly.

Cheers,

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