[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100123051717.GA26471@elte.hu>
Date: Sat, 23 Jan 2010 06:17:17 +0100
From: Ingo Molnar <mingo@...e.hu>
To: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
andi@...stfloor.org, tglx@...utronix.de,
Borislav Petkov <petkovbb@...glemail.com>,
Andreas Herrmann <andreas.herrmann3@....com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Cc: linux-tip-commits@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [tip:x86/mce] x86, mce: Rename cpu_specific_poll to
mce_cpu_specific_poll
* tip-bot for H. Peter Anvin <hpa@...or.com> wrote:
> Commit-ID: f91c4d2649531cc36e10c6bc0f92d0f99116b209
> Gitweb: http://git.kernel.org/tip/f91c4d2649531cc36e10c6bc0f92d0f99116b209
> Author: H. Peter Anvin <hpa@...or.com>
> AuthorDate: Thu, 21 Jan 2010 18:31:54 -0800
> Committer: H. Peter Anvin <hpa@...or.com>
> CommitDate: Thu, 21 Jan 2010 18:31:54 -0800
>
> x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll
>
> cpu_specific_poll is a global variable, and it should have a global
> namespace name. Since it is MCE-specific (it takes a struct mce *),
> rename it mce_cpu_specific_poll.
>
> Signed-off-by: H. Peter Anvin <hpa@...or.com>
> Cc: Andi Kleen <andi@...stfloor.org>
> LKML-Reference: <20100121221711.GA8242@...il.fritz.box>
FYI, this commit triggered a -tip test failure:
arch/x86/kernel/cpu/mcheck/mce-xeon75xx.c: In function 'xeon75xx_mce_init':
arch/x86/kernel/cpu/mcheck/mce-xeon75xx.c:340: error: implicit declaration of function 'pci_match_id'
I'm excluding it from tip:master.
But the bigger problem with this commit is structure of it - or the lack
thereof.
It just blindly goes into the direction the MCE code has been going for some
time, minimally enabling the hardware, ignoring both the new EDAC design and
the new performance monitoring related design i outlined some time ago.
Newly introduced MCE code in the x86 tree should be integrated much better
into existing higher level facilities, not just limp along ignoring life
outside of its little box. This will have to be addressed before we can
reintroduce this commit, even if this trivial build failure is addressed.
I've Cc:-ed a few more interested parties.
Thanks,
Ingo
--
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