From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Jones Subject: Re: cpufreq on ARM broken Date: Wed, 2 Jun 2004 13:59:08 +0100 Sender: cpufreq-bounces@www.linux.org.uk Message-ID: <20040602125908.GM1265@redhat.com> 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> 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: 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. So how come grepping for STICKY in arch/i386/kernel/cpu/cpufreq didn't turn anything up? > 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. Ok, I've no real objection either way. It just seemed odd to have this functionality around, that no-one was using, which just happened to be the right fix. I'll roll this in later, right now there's some corruption in the cpufreq bk tree which the bitmover folks are looking into. Dave