linux-kernel - Re: [RFC PATCH] clk: add extension API

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: <4FC79F61.6030907@wwwdotorg.org>
Date:	Thu, 31 May 2012 10:42:09 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Peter De Schrijver <pdeschrijver@...dia.com>
CC:	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Mike Turquette <mturquette@...com>
Subject: Re: [RFC PATCH] clk: add extension API

On 05/29/2012 03:58 AM, Peter De Schrijver wrote:
> Add an extension API for clocks. This allows clocktypes to provide extensions
> for features which are uncommon and cannot be easily mapped onto normal clock
> framework concecpts. eg: resetting blocks, configuring clock phase etc.

I'm not sure that we should expose module reset as an operation on a clock.

In Tegra, there are resets that affect multiple clocks (well, they
affect portions of HW that use multiple clocks, not the clocks themselves).

Conversely, it's possible in general that there could be some clock
domains where different subsets of the clock domain are affected by
different reset domains.

Tieing the clock and reset domains together doesn't seem correct. A
separate reset API (and perhaps reset binding for DT) might make more sense.
--
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/