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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Mar 2012 19:54:43 -0500 From: Rob Herring <robherring2@...il.com> To: Sascha Hauer <s.hauer@...gutronix.de> CC: Paul Walmsley <paul@...an.com>, Nicolas Pitre <nicolas.pitre@...aro.org>, linaro-dev@...ts.linaro.org, Saravana Kannan <skannan@...eaurora.org>, Jeremy Kerr <jeremy.kerr@...onical.com>, Russell King <linux@....linux.org.uk>, Magnus Damm <magnus.damm@...il.com>, linux-arm-kernel@...ts.infradead.org, Arnd Bergmann <arnd@...db.de>, patches@...aro.org, Rob Herring <rob.herring@...xeda.com>, Thomas Gleixner <tglx@...utronix.de>, linux-omap@...r.kernel.org, Linus Walleij <linus.walleij@...ricsson.com>, Mark Brown <broonie@...nsource.wolfsonmicro.com>, Stephen Boyd <sboyd@...eaurora.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v7 1/3] Documentation: common clk API On 03/16/2012 06:47 PM, Sascha Hauer wrote: > Hi Paul, > > On Fri, Mar 16, 2012 at 04:21:17PM -0600, Paul Walmsley wrote: >> Hi >> >> On Fri, 16 Mar 2012, Arnd Bergmann wrote: >> >> >> If the common clock code is to go upstream now, it should be marked as >> experimental. > > No, please don't do this. This effectively marks the architectures using > the generic clock framework experimental. We can mark drivers as 'you > have been warned', but marking an architecture as experimental is the > wrong sign for both its users and people willing to adopt the framework. > Also we get this: > > warning: (ARCH_MX1 && MACH_MX21 && ARCH_MX25 && MACH_MX27) selects COMMON_CLK which has unmet direct dependencies (EXPERIMENTAL) > > (and no, I don't want to support to clock frameworks in parallel) > +1 For simple users at least, the api is perfectly adequate and it is not experimental (unless new means experimental). Rob >> This is because we know the API is not well-defined, and >> that both the API and the underlying mechanics will almost certainly need >> to change for non-trivial uses of the rate changing code (e.g., DVFS with >> external I/O devices). > > Please leave DVFS out of the game. DVFS will use the clock framework for > the F part and the regulator framework for the V part, but the clock > framework should not get extended with DVFS features. The notifiers we > currently have in the clock framework should give enough information > for DVFS implementations. Even if they don't and we have to change > something here this will have no influence on the architectures > implementing their clock tree with the common clock framework. > > Sascha > -- 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/
Powered by blists - more mailing lists