public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@amd64.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: mingo@elte.hu, tglx@linutronix.de, x86@kernel.org,
	linux-kernel@vger.kernel.org, Frank Arnold <frank.arnold@amd.com>
Subject: Re: [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35
Date: Sat, 24 Apr 2010 10:21:05 +0200	[thread overview]
Message-ID: <20100424082105.GA22632@aftab> (raw)
In-Reply-To: <4BD1E197.6000508@zytor.com>

From: "H. Peter Anvin" <hpa@zytor.com>
Date: Fri, Apr 23, 2010 at 11:06:15AM -0700

> On 04/23/2010 07:09 AM, Borislav Petkov wrote:
> > 
> > Ok, looking at the k8.o object it is 507 bytes so I don't think
> > compiling it in would hurt embedded people too much:
> > 
> >    text    data     bss     dec     hex filename
> >     379     104      24     507     1fb arch/x86/kernel/k8.o
> > 
> > So how about the following? It should apply cleanly on top and it
> > survived a bunch of randconfigs here so far.
> > 
> 
> I have to say I think that's pretty ridiculous for someone who cares so
> much about size that they have disabled CONFIG_PCI that they can just
> add another half-kilobyte of code that is going to do absolutely
> nothing.  Think about the kind of x86 CPUs that could even consider
> disabling CONFIG_PCI -- we're talking pretty deep embedded by now.

Yep, true story.

> So, no, I don't think this is an option.  Force-enabling CONFIG_PCI on
> x86 would be a more realistic option, and I honestly don't know how many
> people would object to that, but not right now.

Well, after looking at 1ac97018169c5a13feaa90d9671f2d6ba2d9e86e,
grepping for '!PCI' in arch/x86/ returns nothing now.

>From all the x86 flavors which didn't need PCI

1) There used to be a X86_VOYAGER MCA-based 32-bit arch from NCR which
seems to be gone now

2) X86_VISWS "SGI 320/540 (Visual Workstation)" depended on !PCI but
depends on PCI now, so which is it?

3) X86_VSMP ("ScaleMP vSMP") used to depend on !PCI but depends on PCI
now, [/me puzzled].

all seem fine with PCI currently (especially the Voyager :)). So it
really looks like we could enable it by default on x86. Maybe for the
.35 merge window and see how much fallout we generate. Or at least put
it up for a flamewar on lkml since we like those so much :).

> The obvious answer instead is to augment the list of stubs in
> <asm/k8.h>.  In particular, move num_k8_northbridges into the #ifdef and
> just #define num_k8_northbridges 0 in the other clause.

Right, it couldn't be simpler, see below. With it, the only warning I
get doing randconfig builds is

arch/x86/kernel/cpu/intel_cacheinfo.c:498: warning: ‘cache_disable_0’ defined but not used
arch/x86/kernel/cpu/intel_cacheinfo.c:500: warning: ‘cache_disable_1’ defined but not used

which is caused by !CONFIG_SYSFS but this is another senseless case.

---
From: Borislav Petkov <borislav.petkov@amd.com>
Date: Sat, 24 Apr 2010 09:56:53 +0200
Subject: [PATCH] x86, k8-nb: Fix build error when K8_NB is disabled

K8_NB depends on PCI and when the last is disabled (allnoconfig) we fail
at the final linking stage due to missing exported num_k8_northbridges.
Add a header stub for that.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
---
 arch/x86/include/asm/k8.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/k8.h b/arch/x86/include/asm/k8.h
index f70e600..af00bd1 100644
--- a/arch/x86/include/asm/k8.h
+++ b/arch/x86/include/asm/k8.h
@@ -16,11 +16,16 @@ extern int k8_numa_init(unsigned long start_pfn, unsigned long end_pfn);
 extern int k8_scan_nodes(void);
 
 #ifdef CONFIG_K8_NB
+extern int num_k8_northbridges;
+
 static inline struct pci_dev *node_to_k8_nb_misc(int node)
 {
 	return (node < num_k8_northbridges) ? k8_northbridges[node] : NULL;
 }
+
 #else
+#define num_k8_northbridges 0
+
 static inline struct pci_dev *node_to_k8_nb_misc(int node)
 {
 	return NULL;
-- 
1.6.4.4


-- 
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center

  reply	other threads:[~2010-04-24  8:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 14:06 [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35 Borislav Petkov
2010-04-22 14:06 ` [PATCH 1/5] x86, cacheinfo: Unify AMD L3 cache index disable checking Borislav Petkov
2010-05-03 22:39   ` [tip:x86/cpu] " tip-bot for Borislav Petkov
2010-04-22 14:06 ` [PATCH 2/5] x86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments Borislav Petkov
2010-05-03 22:39   ` [tip:x86/cpu] " tip-bot for Frank Arnold
2010-05-14 18:48   ` [tip:x86/urgent] " tip-bot for Frank Arnold
2010-05-14 19:01   ` tip-bot for Frank Arnold
2010-05-15 19:29   ` [PATCH 2/5] " Jaswinder Singh Rajput
2010-05-17 19:05     ` Jaswinder Singh Rajput
2010-04-22 14:07 ` [PATCH 3/5] x86, cacheinfo: Reorganize AMD L3 cache structure Borislav Petkov
2010-05-03 22:40   ` [tip:x86/cpu] " tip-bot for Borislav Petkov
2010-04-22 14:07 ` [PATCH 4/5] x86, cacheinfo: Make L3 cache info per node Borislav Petkov
2010-05-03 22:40   ` [tip:x86/cpu] " tip-bot for Borislav Petkov
2010-04-22 14:07 ` [PATCH 5/5] x86, cacheinfo: Disable index in all four subcaches Borislav Petkov
2010-05-03 22:40   ` [tip:x86/cpu] " tip-bot for Borislav Petkov
2010-04-23  0:23 ` [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35 H. Peter Anvin
2010-04-23  6:50   ` Borislav Petkov
2010-04-23 14:09     ` Borislav Petkov
2010-04-23 18:06       ` H. Peter Anvin
2010-04-24  8:21         ` Borislav Petkov [this message]
2010-05-03 18:20           ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100424082105.GA22632@aftab \
    --to=bp@amd64.org \
    --cc=frank.arnold@amd.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox