From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King Subject: Re: cpufreq on ARM broken Date: Wed, 2 Jun 2004 22:36:19 +0100 Sender: cpufreq-bounces@www.linux.org.uk Message-ID: <20040602223619.C9322@flint.arm.linux.org.uk> References: <20040529170151.B3799@flint.arm.linux.org.uk> <1086109894.27727.24.camel@delerium.codemonkey.org.uk> <20040602122153.GB8781@dominikbrodowski.de> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20040602122153.GB8781@dominikbrodowski.de>; from linux@dominikbrodowski.de on Wed, Jun 02, 2004 at 02:21:53PM +0200 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cpufreq-bounces+glkc-cpufreq=gmane.org@www.linux.org.uk Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Dave Jones , cpufreq@www.linux.org.uk On Wed, Jun 02, 2004 at 02:21:53PM +0200, Dominik Brodowski wrote: > On Tue, Jun 01, 2004 at 06:11:34PM +0100, Dave Jones wrote: > > Thoughts ? > > I've forgotten why we introduced this flag, it appears that this > > would be the first thing in the tree to actually use it, > > which makes me sceptical. > > This flag was introduced when I added the "fail if no proper CPU found" > feature, which is helpful for the ACPI P-States driver and some other x86 > drivers which only check whether they can run on _any_ CPU in the > cpu-specific initialization call. To assert backwards-compatibility, this > flag avoids "automatic unregistration" -- I wasn't aware some drivers do > need this backwards compatibility, but obviously ARM needs it. So Russell's > patch looks to be what's needed, from my perspective. It isn't back-compat. It's caused by a side effect of how the order of initialisation. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core