Re: + x86-show-cpuinfo-only-for-online-cpus.patch added to -mm tree
On Thu, Nov 01, 2007 at 03:31:23PM -0700, Yinghai Lu wrote: > > wonder if could change > > > if (!cpu_online(c->cpu_index)) > > return 0; > > ==> > > > if (c->cpu_index >= NR_CPUS) > > return 0; > > and add another entry for every cpu > online : 1 when it is enabled > or online : 0 when it is disabled by /sys/devices/system/cpuX/online. No, I don't think that would be a good idea. It would change the usual behaviour of that interface (to display only CPUs that are "up and running".) Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch2/2] fix wrong proc cpuinfo on x64
On Tue, Nov 06, 2007 at 04:28:20PM +0800, Zou Nan hai wrote: > in 2.6.24-rc1 kernel, > The /proc/cpuinfo display is wrong. > > Another issue is that it will display bogus cpus with wrong information > if the kernel is compiled with a big CONFIG_NR_CPU. > > That is because before a cpu in cpu_present_map is up, c->cpu_index of > that cpu is 0. > thus the cpu_online(c->cpu_index) check in show_cpuinfo is invalid. This issue should already be fixed with that patch http://marc.info/?l=linux-kernel=119394201230954 > This patch will let cpuinfo_op use cpu_online_map instead of > cpu_present_map to iterate cpus. BTW, the problem affects i386 as well. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch1/2] fix wrong proc cpuinfo on x64
On Tue, Nov 06, 2007 at 03:25:39PM +0800, Zou Nan hai wrote: > > in 2.6.24-rc1 kernel, > The /proc/cpuinfo display is wrong. > > One issue is every processor id appears to be 0. > > That is because smp_store_cpu_info will set cpuinfo_x86->cpu_index > to cpu id then call identify_cpu > identify_cpu will call early_identify_cpu which set c->cpu_index back to > 0. This issue should already be fixed with this patch http://marc.info/?l=linux-kernel=119392088227245 Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch1/2] fix wrong proc cpuinfo on x64
On Tue, Nov 06, 2007 at 03:25:39PM +0800, Zou Nan hai wrote: in 2.6.24-rc1 kernel, The /proc/cpuinfo display is wrong. One issue is every processor id appears to be 0. That is because smp_store_cpu_info will set cpuinfo_x86-cpu_index to cpu id then call identify_cpu identify_cpu will call early_identify_cpu which set c-cpu_index back to 0. This issue should already be fixed with this patch http://marc.info/?l=linux-kernelm=119392088227245 Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch2/2] fix wrong proc cpuinfo on x64
On Tue, Nov 06, 2007 at 04:28:20PM +0800, Zou Nan hai wrote: in 2.6.24-rc1 kernel, The /proc/cpuinfo display is wrong. Another issue is that it will display bogus cpus with wrong information if the kernel is compiled with a big CONFIG_NR_CPU. That is because before a cpu in cpu_present_map is up, c-cpu_index of that cpu is 0. thus the cpu_online(c-cpu_index) check in show_cpuinfo is invalid. This issue should already be fixed with that patch http://marc.info/?l=linux-kernelm=119394201230954 This patch will let cpuinfo_op use cpu_online_map instead of cpu_present_map to iterate cpus. BTW, the problem affects i386 as well. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + x86-show-cpuinfo-only-for-online-cpus.patch added to -mm tree
On Thu, Nov 01, 2007 at 03:31:23PM -0700, Yinghai Lu wrote: wonder if could change if (!cpu_online(c-cpu_index)) return 0; == if (c-cpu_index = NR_CPUS) return 0; and add another entry for every cpu online : 1 when it is enabled or online : 0 when it is disabled by /sys/devices/system/cpuX/online. No, I don't think that would be a good idea. It would change the usual behaviour of that interface (to display only CPUs that are up and running.) Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: fix cpu-hotplug regression
[PATCH] x86: fix cpu-hotplug regression Commit d435d862baca3e25e5eec236762a43251b1e7ffc (cpu hotplug: mce: fix cpu hotplug error handling) changed the error handling in mce_cpu_callback. In cases where not all CPUs are brought up during boot (e.g. using maxcpus and additional_cpus parameters) mce_cpu_callback now returns NOTFIY_BAD because for such CPUs cpu_data is not completely filled when the notifier is called. Thus mce_create_device fails right at its beginning: if (!mce_available(cpu_data[cpu])) return -EIO; As a quick fix I suggest to check boot_cpu_data for MCE. To reproduce this regression: (1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system (2) # echo 1 /sys/devices/system/cpu/cpu2/online -bash: echo: write error: Invalid argument dmesg shows: _cpu_up: attempt to bring up CPU 2 failed Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- arch/x86/kernel/cpu/mcheck/mce_64.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/cpu/mcheck/mce_64.c b/arch/x86/kernel/cpu/mcheck/mce_64.c index b9f802e..5112a70 100644 --- a/arch/x86/kernel/cpu/mcheck/mce_64.c +++ b/arch/x86/kernel/cpu/mcheck/mce_64.c @@ -808,7 +808,7 @@ static __cpuinit int mce_create_device(unsigned int cpu) int err; int i; - if (!mce_available(cpu_data(cpu))) + if (!mce_available(boot_cpu_data)) return -EIO; memset(per_cpu(device_mce, cpu).kobj, 0, sizeof(struct kobject)); -- 1.5.3.4 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] x86: show cpuinfo only for online CPUs
New version of the fix.
Now it works also in the non-SMP case.
Tested on x86_64.
Regards,
Andreas
--
[PATCH] x86: show cpuinfo only for online CPUs
Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563.
It can happen that cpuinfo is displayed for CPUs that are not online or
even worse for CPUs not present at all. As an example, following was
shown for a "second" CPU of a single core K8 variant:
processor : 0
vendor_id : unknown
cpu family : 0
model : 0
model name : unknown
stepping: 0
cache size : 0 KB
fpu : yes
fpu_exception : yes
cpuid level : 0
wp : yes
flags :
bogomips: 0.00
clflush size: 0
cache_alignment : 0
address sizes : 0 bits physical, 0 bits virtual
power management:
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/proc.c |8 +++-
arch/x86/kernel/setup_64.c |8 +++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 066f8c6..3900e46 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -89,8 +89,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
int fpu_exception;
#ifdef CONFIG_SMP
- if (!cpu_online(n))
- return 0;
n = c->cpu_index;
#endif
seq_printf(m, "processor\t: %d\n"
@@ -177,14 +175,14 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) < NR_CPUS && cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) < NR_CPUS && cpu_online(*pos))
return _data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
static void c_stop(struct seq_file *m, void *v)
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index ec59fcb..30d94d1 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -1077,8 +1077,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
#ifdef CONFIG_SMP
- if (!cpu_online(c->cpu_index))
- return 0;
cpu = c->cpu_index;
#endif
@@ -1170,15 +1168,15 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) < NR_CPUS && cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) < NR_CPUS && cpu_online(*pos))
return _data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
--
1.5.3.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: show cpuinfo only for online CPUs
This patch applies on current Linus' git with Glauber's recent cpuinfo fix
(http://marc.info/?l=linux-kernel=119392088227245) applied.
Regards,
Andreas
--
[PATCH] x86: show cpuinfo only for online CPUs
Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563.
It can happen that cpuinfo is displayed for CPUs that are not online or
even worse for CPUs not present at all. As an example, following was
shown for a "second" CPU of a single core K8 variant:
processor : 0
vendor_id : unknown
cpu family : 0
model : 0
model name : unknown
stepping: 0
cache size : 0 KB
fpu : yes
fpu_exception : yes
cpuid level : 0
wp : yes
flags :
bogomips: 0.00
clflush size: 0
cache_alignment : 0
address sizes : 0 bits physical, 0 bits virtual
power management:
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
arch/x86/kernel/cpu/proc.c | 13 -
arch/x86/kernel/setup_64.c | 15 ---
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 066f8c6..13cfd85 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -85,14 +85,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
/* nothing */
};
struct cpuinfo_x86 *c = v;
- int i, n = 0;
+ int i, n = c->cpu_index;
int fpu_exception;
-#ifdef CONFIG_SMP
- if (!cpu_online(n))
- return 0;
- n = c->cpu_index;
-#endif
seq_printf(m, "processor\t: %d\n"
"vendor_id\t: %s\n"
"cpu family\t: %d\n"
@@ -177,14 +172,14 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) < NR_CPUS && cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) < NR_CPUS && cpu_online(*pos))
return _data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
static void c_stop(struct seq_file *m, void *v)
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index ec59fcb..480230a 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -998,7 +998,7 @@ void __cpuinit print_cpu_info(struct cpuinfo_x86 *c)
static int show_cpuinfo(struct seq_file *m, void *v)
{
struct cpuinfo_x86 *c = v;
- int cpu = 0;
+ int cpu = c->cpu_index;
/*
* These flag bits must match the definitions in .
@@ -1075,13 +1075,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
/* nothing */
};
-
-#ifdef CONFIG_SMP
- if (!cpu_online(c->cpu_index))
- return 0;
- cpu = c->cpu_index;
-#endif
-
seq_printf(m,"processor\t: %u\n"
"vendor_id\t: %s\n"
"cpu family\t: %d\n"
@@ -1170,15 +1163,15 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) < NR_CPUS && cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) < NR_CPUS && cpu_online(*pos))
return _data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
--
1.5.3.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: show cpuinfo only for online CPUs
This patch applies on current Linus' git with Glauber's recent cpuinfo fix
(http://marc.info/?l=linux-kernelm=119392088227245) applied.
Regards,
Andreas
--
[PATCH] x86: show cpuinfo only for online CPUs
Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563.
It can happen that cpuinfo is displayed for CPUs that are not online or
even worse for CPUs not present at all. As an example, following was
shown for a second CPU of a single core K8 variant:
processor : 0
vendor_id : unknown
cpu family : 0
model : 0
model name : unknown
stepping: 0
cache size : 0 KB
fpu : yes
fpu_exception : yes
cpuid level : 0
wp : yes
flags :
bogomips: 0.00
clflush size: 0
cache_alignment : 0
address sizes : 0 bits physical, 0 bits virtual
power management:
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/proc.c | 13 -
arch/x86/kernel/setup_64.c | 15 ---
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 066f8c6..13cfd85 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -85,14 +85,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
/* nothing */
};
struct cpuinfo_x86 *c = v;
- int i, n = 0;
+ int i, n = c-cpu_index;
int fpu_exception;
-#ifdef CONFIG_SMP
- if (!cpu_online(n))
- return 0;
- n = c-cpu_index;
-#endif
seq_printf(m, processor\t: %d\n
vendor_id\t: %s\n
cpu family\t: %d\n
@@ -177,14 +172,14 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) NR_CPUS cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) NR_CPUS cpu_online(*pos))
return cpu_data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
static void c_stop(struct seq_file *m, void *v)
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index ec59fcb..480230a 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -998,7 +998,7 @@ void __cpuinit print_cpu_info(struct cpuinfo_x86 *c)
static int show_cpuinfo(struct seq_file *m, void *v)
{
struct cpuinfo_x86 *c = v;
- int cpu = 0;
+ int cpu = c-cpu_index;
/*
* These flag bits must match the definitions in asm/cpufeature.h.
@@ -1075,13 +1075,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
/* nothing */
};
-
-#ifdef CONFIG_SMP
- if (!cpu_online(c-cpu_index))
- return 0;
- cpu = c-cpu_index;
-#endif
-
seq_printf(m,processor\t: %u\n
vendor_id\t: %s\n
cpu family\t: %d\n
@@ -1170,15 +1163,15 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) NR_CPUS cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) NR_CPUS cpu_online(*pos))
return cpu_data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
--
1.5.3.4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] x86: show cpuinfo only for online CPUs
New version of the fix.
Now it works also in the non-SMP case.
Tested on x86_64.
Regards,
Andreas
--
[PATCH] x86: show cpuinfo only for online CPUs
Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563.
It can happen that cpuinfo is displayed for CPUs that are not online or
even worse for CPUs not present at all. As an example, following was
shown for a second CPU of a single core K8 variant:
processor : 0
vendor_id : unknown
cpu family : 0
model : 0
model name : unknown
stepping: 0
cache size : 0 KB
fpu : yes
fpu_exception : yes
cpuid level : 0
wp : yes
flags :
bogomips: 0.00
clflush size: 0
cache_alignment : 0
address sizes : 0 bits physical, 0 bits virtual
power management:
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
arch/x86/kernel/cpu/proc.c |8 +++-
arch/x86/kernel/setup_64.c |8 +++-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 066f8c6..3900e46 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -89,8 +89,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
int fpu_exception;
#ifdef CONFIG_SMP
- if (!cpu_online(n))
- return 0;
n = c-cpu_index;
#endif
seq_printf(m, processor\t: %d\n
@@ -177,14 +175,14 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) NR_CPUS cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) NR_CPUS cpu_online(*pos))
return cpu_data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
static void c_stop(struct seq_file *m, void *v)
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index ec59fcb..30d94d1 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -1077,8 +1077,6 @@ static int show_cpuinfo(struct seq_file *m, void *v)
#ifdef CONFIG_SMP
- if (!cpu_online(c-cpu_index))
- return 0;
cpu = c-cpu_index;
#endif
@@ -1170,15 +1168,15 @@ static int show_cpuinfo(struct seq_file *m, void *v)
static void *c_start(struct seq_file *m, loff_t *pos)
{
if (*pos == 0) /* just in case, cpu 0 is not the first */
- *pos = first_cpu(cpu_possible_map);
- if ((*pos) NR_CPUS cpu_possible(*pos))
+ *pos = first_cpu(cpu_online_map);
+ if ((*pos) NR_CPUS cpu_online(*pos))
return cpu_data(*pos);
return NULL;
}
static void *c_next(struct seq_file *m, void *v, loff_t *pos)
{
- *pos = next_cpu(*pos, cpu_possible_map);
+ *pos = next_cpu(*pos, cpu_online_map);
return c_start(m, pos);
}
--
1.5.3.4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sat, Sep 22, 2007 at 07:27:59AM +0200, Mihai Donțu wrote: > Hi, > > Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet > weekend). > Anyway, it seems that radeonfb and my: > "01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS > 200M 5955 (PCIE)" > don't get along anymore, by: > a) X somehow fails to initialize the card and everything moves really slow (I > can >see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff > appears >on the screen; Have you tried to boot your kernel with video=radeonfb:noaccel I usual add this kernel parameter when running radeonfb and X. Otherwise I've observed the same symptoms (e.g. with my radeon card at home: Radeon X300SE, 1002:5b70). Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc7 + radeonfb/s2ram
On Sat, Sep 22, 2007 at 07:27:59AM +0200, Mihai Donțu wrote: Hi, Today, out of curiosity, I pulled 2.6.23-rc7 (leave on the edge in a quiet weekend). Anyway, it seems that radeonfb and my: 01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) don't get along anymore, by: a) X somehow fails to initialize the card and everything moves really slow (I can see how surfaces are drawn pixel-by-pixel); furthermore, garbage stuff appears on the screen; Have you tried to boot your kernel with video=radeonfb:noaccel I usual add this kernel parameter when running radeonfb and X. Otherwise I've observed the same symptoms (e.g. with my radeon card at home: Radeon X300SE, 1002:5b70). Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL
On Wed, Sep 19, 2007 at 11:31:10PM -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann <[EMAIL PROTECTED]> wrote:
>
> > Fix compile error if !CONFIG_SYSCTL:
> >
> > ...
> > LD .tmp_vmlinux1
> > net/built-in.o: In function `init_p9':
> > net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> > net/built-in.o: In function `exit_p9':
> > net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> > make: *** [.tmp_vmlinux1] Error 1
> > ...
>
> A better fix would be
But only if you add another
#endif /* CONFIG_SYSCTL */
Right?
;-)
>
> --- a/include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl
> +++ a/include/net/9p/9p.h
> @@ -412,6 +412,17 @@ int p9_idpool_check(int id, struct p9_id
>
> int p9_error_init(void);
> int p9_errstr2errno(char *, int);
> +#ifdef CONFIG_SYSCTL
> int __init p9_sysctl_register(void);
> void __exit p9_sysctl_unregister(void);
> +#else
> +static inline int p9_sysctl_register(void)
> +{
> + return 0;
> +}
> +
> +static inline void p9_sysctl_unregister(void)
> +{
> +}
> +
> #endif /* NET_9P_H */
> diff -puN net/9p/mod.c~9p-fix-compile-error-if-config_sysctl net/9p/mod.c
> _
>
> I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
> go away and gave up in disgust.
>
> God I hate select.
Hmm, you mean to completely avoid "#ifdef CONFIG_SYSCTL" in the net/p9 code?
How about below patch, which just merges net/9p/sysctl.c into net/9p/mod.c.
Regards,
Andreas
--
Merge net/p9/sysctl.c into net/p9/mod.c to avoid build errors
if !CONFIG_SYSCTL.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
include/net/9p/9p.h |2 -
net/9p/Makefile |4 +--
net/9p/mod.c| 54 +
net/9p/sysctl.c | 81 ---
4 files changed, 48 insertions(+), 93 deletions(-)
delete mode 100644 net/9p/sysctl.c
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 4d3..f69992f 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,4 @@ int p9_idpool_check(int id, struct p9_idpool *p);
int p9_error_init(void);
int p9_errstr2errno(char *, int);
-int __init p9_sysctl_register(void);
-void __exit p9_sysctl_unregister(void);
#endif /* NET_9P_H */
diff --git a/net/9p/Makefile b/net/9p/Makefile
index 85b3a78..488026a 100644
--- a/net/9p/Makefile
+++ b/net/9p/Makefile
@@ -8,6 +8,4 @@ obj-$(CONFIG_NET_9P) := 9pnet.o
conv.o \
error.o \
fcprint.o \
- util.o \
-
-9pnet-$(CONFIG_SYSCTL) += sysctl.o
+ util.o
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..8d4ce1b 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -24,6 +24,10 @@
*
*/
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -37,8 +41,44 @@ MODULE_PARM_DESC(debug, "9P debugging level");
extern int p9_mux_global_init(void);
extern void p9_mux_global_exit(void);
-extern int p9_sysctl_register(void);
-extern void p9_sysctl_unregister(void);
+
+static struct ctl_table p9_table[] = {
+#ifdef CONFIG_NET_9P_DEBUG
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "debug",
+ .data = _debug_level,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = _dointvec
+ },
+#endif
+ {},
+};
+
+static struct ctl_table p9_net_table[] = {
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "9p",
+ .maxlen = 0,
+ .mode = 0555,
+ .child = p9_table,
+ },
+ {},
+};
+
+static struct ctl_table p9_ctl_table[] = {
+ {
+ .ctl_name = CTL_NET,
+ .procname = "net",
+ .maxlen = 0,
+ .mode = 0555,
+ .child = p9_net_table,
+ },
+ {},
+};
+
+static struct ctl_table_header *p9_table_header;
/**
* v9fs_init - Initialize module
@@ -56,13 +96,13 @@ static int __init init_p9(void)
return ret;
}
- ret = p9_sysctl_register();
- if (ret) {
+ p9_table_header = register_sysctl_table(p9_ctl_table);
+ if (!p9_table_header) {
printk(KERN_WARNING "9p: registering sysctl failed\n");
- return ret;
+ return -ENOMEM;
}
- return ret;
+ return 0;
}
/**
@@ -72,7 +112,7 @@ static int __init init_p9(void)
static void __exit exit_p9(void)
{
- p9_sysctl_unregister();
+ unregister_sysctl_table(p9_table_header);
p9_mux_global_exit();
}
diff --git a/n
Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL
On Wed, Sep 19, 2007 at 11:31:10PM -0700, Andrew Morton wrote:
On Tue, 18 Sep 2007 10:05:37 +0200 Andreas Herrmann [EMAIL PROTECTED] wrote:
Fix compile error if !CONFIG_SYSCTL:
...
LD .tmp_vmlinux1
net/built-in.o: In function `init_p9':
net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
make: *** [.tmp_vmlinux1] Error 1
...
A better fix would be
But only if you add another
#endif /* CONFIG_SYSCTL */
Right?
;-)
--- a/include/net/9p/9p.h~9p-fix-compile-error-if-config_sysctl
+++ a/include/net/9p/9p.h
@@ -412,6 +412,17 @@ int p9_idpool_check(int id, struct p9_id
int p9_error_init(void);
int p9_errstr2errno(char *, int);
+#ifdef CONFIG_SYSCTL
int __init p9_sysctl_register(void);
void __exit p9_sysctl_unregister(void);
+#else
+static inline int p9_sysctl_register(void)
+{
+ return 0;
+}
+
+static inline void p9_sysctl_unregister(void)
+{
+}
+
#endif /* NET_9P_H */
diff -puN net/9p/mod.c~9p-fix-compile-error-if-config_sysctl net/9p/mod.c
_
I struggled for five minutes trying to work out how to make CONFIG_SYSCTL
go away and gave up in disgust.
God I hate select.
Hmm, you mean to completely avoid #ifdef CONFIG_SYSCTL in the net/p9 code?
How about below patch, which just merges net/9p/sysctl.c into net/9p/mod.c.
Regards,
Andreas
--
Merge net/p9/sysctl.c into net/p9/mod.c to avoid build errors
if !CONFIG_SYSCTL.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
include/net/9p/9p.h |2 -
net/9p/Makefile |4 +--
net/9p/mod.c| 54 +
net/9p/sysctl.c | 81 ---
4 files changed, 48 insertions(+), 93 deletions(-)
delete mode 100644 net/9p/sysctl.c
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 4d3..f69992f 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,4 @@ int p9_idpool_check(int id, struct p9_idpool *p);
int p9_error_init(void);
int p9_errstr2errno(char *, int);
-int __init p9_sysctl_register(void);
-void __exit p9_sysctl_unregister(void);
#endif /* NET_9P_H */
diff --git a/net/9p/Makefile b/net/9p/Makefile
index 85b3a78..488026a 100644
--- a/net/9p/Makefile
+++ b/net/9p/Makefile
@@ -8,6 +8,4 @@ obj-$(CONFIG_NET_9P) := 9pnet.o
conv.o \
error.o \
fcprint.o \
- util.o \
-
-9pnet-$(CONFIG_SYSCTL) += sysctl.o
+ util.o
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..8d4ce1b 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -24,6 +24,10 @@
*
*/
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/sysctl.h
+#include linux/init.h
#include linux/module.h
#include linux/moduleparam.h
#include net/9p/9p.h
@@ -37,8 +41,44 @@ MODULE_PARM_DESC(debug, 9P debugging level);
extern int p9_mux_global_init(void);
extern void p9_mux_global_exit(void);
-extern int p9_sysctl_register(void);
-extern void p9_sysctl_unregister(void);
+
+static struct ctl_table p9_table[] = {
+#ifdef CONFIG_NET_9P_DEBUG
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = debug,
+ .data = p9_debug_level,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+#endif
+ {},
+};
+
+static struct ctl_table p9_net_table[] = {
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = 9p,
+ .maxlen = 0,
+ .mode = 0555,
+ .child = p9_table,
+ },
+ {},
+};
+
+static struct ctl_table p9_ctl_table[] = {
+ {
+ .ctl_name = CTL_NET,
+ .procname = net,
+ .maxlen = 0,
+ .mode = 0555,
+ .child = p9_net_table,
+ },
+ {},
+};
+
+static struct ctl_table_header *p9_table_header;
/**
* v9fs_init - Initialize module
@@ -56,13 +96,13 @@ static int __init init_p9(void)
return ret;
}
- ret = p9_sysctl_register();
- if (ret) {
+ p9_table_header = register_sysctl_table(p9_ctl_table);
+ if (!p9_table_header) {
printk(KERN_WARNING 9p: registering sysctl failed\n);
- return ret;
+ return -ENOMEM;
}
- return ret;
+ return 0;
}
/**
@@ -72,7 +112,7 @@ static int __init init_p9(void)
static void __exit exit_p9(void)
{
- p9_sysctl_unregister();
+ unregister_sysctl_table(p9_table_header);
p9_mux_global_exit();
}
diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
deleted file mode 100644
index 8b61027..000
--- a/net/9p/sysctl.c
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * net/9p/sysctl.c
- *
- * 9P sysctl interface
Re: Problem: one driver and 4 instances with different parameters
On Wed, Sep 19, 2007 at 08:54:58AM +0200, Andrey Kamchatnikov wrote: > I have one driver, but I need to run 4 instances of it (I run insmod with > different > parameters) . > > But when I try to install the second driver I've got an error, that driver > with this name > exists. It might work using modprobe's "--name"-option: # modprobe -o foo driver # modprobe -o bar driver Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem: one driver and 4 instances with different parameters
On Wed, Sep 19, 2007 at 08:54:58AM +0200, Andrey Kamchatnikov wrote: I have one driver, but I need to run 4 instances of it (I run insmod with different parameters) . But when I try to install the second driver I've got an error, that driver with this name exists. It might work using modprobe's --name-option: # modprobe -o foo driver # modprobe -o bar driver Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL
On Tue, Sep 18, 2007 at 08:53:19PM +0200, roel wrote:
> Andreas Herrmann wrote:
> > Fix compile error if !CONFIG_SYSCTL:
> >
> > ...
> > LD .tmp_vmlinux1
> > net/built-in.o: In function `init_p9':
> > net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
> > net/built-in.o: In function `exit_p9':
> > net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
> > make: *** [.tmp_vmlinux1] Error 1
> > ...
> >
> isn't it nicer to do something like this instead?
No.
> diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
> index 8b61027..e199865 100644
> --- a/net/9p/sysctl.c
> +++ b/net/9p/sysctl.c
> @@ -68,14 +68,17 @@ static struct ctl_table_header *p9_table_header;
>
> int __init p9_sysctl_register(void)
> {
> +#ifdef CONFIG_SYSCTL
> p9_table_header = register_sysctl_table(p9_ctl_table);
> if (!p9_table_header)
> return -ENOMEM;
> -
> +#endif
> return 0;
> }
>
> void __exit p9_sysctl_unregister(void)
> {
> +#ifdef CONFIG_SYSCTL
>unregister_sysctl_table(p9_table_header);
> +#endif
> }
The problem is not that (un)register_sysctl_table were not defined
if !CONFIG_SYSCTL. There are stubs in kernel/sysctl.c for this case.
I.e. your patch is superfluous.
The point is, 9p/sysctl.c is compiled iff CONFIG_SYSCTL is set.
See net/9p/Makefile ...
Regards,
Andreas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 9p: fix compile error if !CONFIG_SYSCTL
Fix compile error if !CONFIG_SYSCTL:
...
LD .tmp_vmlinux1
net/built-in.o: In function `init_p9':
net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
make: *** [.tmp_vmlinux1] Error 1
...
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
include/net/9p/9p.h |4
net/9p/mod.c|4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 4d3..f723a03 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,10 @@ int p9_idpool_check(int id, struct p9_idpool *p);
int p9_error_init(void);
int p9_errstr2errno(char *, int);
+
+#ifdef CONFIG_SYSCTL
int __init p9_sysctl_register(void);
void __exit p9_sysctl_unregister(void);
+#endif
+
#endif /* NET_9P_H */
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..b4d435c 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -56,11 +56,13 @@ static int __init init_p9(void)
return ret;
}
+#ifdef CONFIG_SYSCTL
ret = p9_sysctl_register();
if (ret) {
printk(KERN_WARNING "9p: registering sysctl failed\n");
return ret;
}
+#endif
return ret;
}
@@ -72,7 +74,9 @@ static int __init init_p9(void)
static void __exit exit_p9(void)
{
+#ifdef CONFIG_SYSCTL
p9_sysctl_unregister();
+#endif
p9_mux_global_exit();
}
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 9p: fix compile error if !CONFIG_SYSCTL
Fix compile error if !CONFIG_SYSCTL:
...
LD .tmp_vmlinux1
net/built-in.o: In function `init_p9':
net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
make: *** [.tmp_vmlinux1] Error 1
...
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
include/net/9p/9p.h |4
net/9p/mod.c|4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/net/9p/9p.h b/include/net/9p/9p.h
index 4d3..f723a03 100644
--- a/include/net/9p/9p.h
+++ b/include/net/9p/9p.h
@@ -412,6 +412,10 @@ int p9_idpool_check(int id, struct p9_idpool *p);
int p9_error_init(void);
int p9_errstr2errno(char *, int);
+
+#ifdef CONFIG_SYSCTL
int __init p9_sysctl_register(void);
void __exit p9_sysctl_unregister(void);
+#endif
+
#endif /* NET_9P_H */
diff --git a/net/9p/mod.c b/net/9p/mod.c
index 4f9e1d2..b4d435c 100644
--- a/net/9p/mod.c
+++ b/net/9p/mod.c
@@ -56,11 +56,13 @@ static int __init init_p9(void)
return ret;
}
+#ifdef CONFIG_SYSCTL
ret = p9_sysctl_register();
if (ret) {
printk(KERN_WARNING 9p: registering sysctl failed\n);
return ret;
}
+#endif
return ret;
}
@@ -72,7 +74,9 @@ static int __init init_p9(void)
static void __exit exit_p9(void)
{
+#ifdef CONFIG_SYSCTL
p9_sysctl_unregister();
+#endif
p9_mux_global_exit();
}
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL
On Tue, Sep 18, 2007 at 08:53:19PM +0200, roel wrote:
Andreas Herrmann wrote:
Fix compile error if !CONFIG_SYSCTL:
...
LD .tmp_vmlinux1
net/built-in.o: In function `init_p9':
net/9p/mod.c:59: undefined reference to `p9_sysctl_register'
net/built-in.o: In function `exit_p9':
net/9p/mod.c:75: undefined reference to `p9_sysctl_unregister'
make: *** [.tmp_vmlinux1] Error 1
...
isn't it nicer to do something like this instead?
No.
diff --git a/net/9p/sysctl.c b/net/9p/sysctl.c
index 8b61027..e199865 100644
--- a/net/9p/sysctl.c
+++ b/net/9p/sysctl.c
@@ -68,14 +68,17 @@ static struct ctl_table_header *p9_table_header;
int __init p9_sysctl_register(void)
{
+#ifdef CONFIG_SYSCTL
p9_table_header = register_sysctl_table(p9_ctl_table);
if (!p9_table_header)
return -ENOMEM;
-
+#endif
return 0;
}
void __exit p9_sysctl_unregister(void)
{
+#ifdef CONFIG_SYSCTL
unregister_sysctl_table(p9_table_header);
+#endif
}
The problem is not that (un)register_sysctl_table were not defined
if !CONFIG_SYSCTL. There are stubs in kernel/sysctl.c for this case.
I.e. your patch is superfluous.
The point is, 9p/sysctl.c is compiled iff CONFIG_SYSCTL is set.
See net/9p/Makefile ...
Regards,
Andreas
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mac_hid: fix build error if MAC_EMUMOUSEBTN && !INPUT
Hi, With current git an invalid kernel configuration is selectable which leads to kernel build errors for mac_hid. To prevent this selection I suggest follwoing patch. Regards, Andreas -- Build error if MAC_EMUMOUSEBTN && !INPUT: LD .tmp_vmlinux1 drivers/built-in.o: In function `input_report_key': include/linux/input.h:1158: undefined reference to `input_event' ... Auto-select INPUT for MAC_EMUMOUSEBTN option. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/macintosh/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig index 56cd899..77f50b6 100644 --- a/drivers/macintosh/Kconfig +++ b/drivers/macintosh/Kconfig @@ -172,6 +172,7 @@ config INPUT_ADBHID config MAC_EMUMOUSEBTN bool "Support for mouse button 2+3 emulation" + select INPUT help This provides generic support for emulating the 2nd and 3rd mouse button with keypresses. If you say Y here, the emulation is still -- 1.5.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mac_hid: fix build error if MAC_EMUMOUSEBTN !INPUT
Hi, With current git an invalid kernel configuration is selectable which leads to kernel build errors for mac_hid. To prevent this selection I suggest follwoing patch. Regards, Andreas -- Build error if MAC_EMUMOUSEBTN !INPUT: LD .tmp_vmlinux1 drivers/built-in.o: In function `input_report_key': include/linux/input.h:1158: undefined reference to `input_event' ... Auto-select INPUT for MAC_EMUMOUSEBTN option. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/macintosh/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig index 56cd899..77f50b6 100644 --- a/drivers/macintosh/Kconfig +++ b/drivers/macintosh/Kconfig @@ -172,6 +172,7 @@ config INPUT_ADBHID config MAC_EMUMOUSEBTN bool Support for mouse button 2+3 emulation + select INPUT help This provides generic support for emulating the 2nd and 3rd mouse button with keypresses. If you say Y here, the emulation is still -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG
Usually one shouldn't reply to such mails. But I cannot resist. Because partially there was told such nonsense ... Of course the following is just my personal view. On 2007-09-13 20:54:41, H. Peter Anvin wrote: > Andreas Herrmann wrote: > > On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: > >> Yinghai Lu wrote: > >>> BIOS guys also said that fam 10h need mmconfig via eax accessing, may > >>> need OS do sth, so it is safe to stay with MCFG entry for SB like > >>> mcp55... > >>> > >>> but latest kernel already have that workaround to make mmconfig via eax... > >>> > >> This is actually a good point. Since the CPU vendor managed to > >> completely fuck up the operation of MMCONFIG itself on this CPU (it's a > >> *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent > >> that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually > >> work on this CPU for any system software which doesn't already know to > >> work around this particular piece of severe braindamage; > > > > But wait, isn't it true that Vista is using MCFG? > > So, poor BIOS guys what should they do now? > > If you have a special problem here why not upgrading your Linux kernel? > > > > I'm not talking about Linux here. I'm talking about any random system > software (which may or may not be Vista, and may nor may not even be an > OS.) Are you serious? You are worried about Vista compatibility issues for new hardware? Here on LKML? I thought this is a Linux mailing list. But if this is your worry: Aren't you aware that most OSes have included patches in order to support this new hardware? Making use of the new pstates stuff is one example. And aren't you aware that even for proprietary OSes there are updates? But if that is not functioning for you why don't you just get rid of your proprietary hoax? > If they advertise MCFG, then a random OS could try to use it, in > accordance with the spec, without the workaround, with serious > malfunction as a result. Have you looked into the BKDG of that CPU? You can download it here http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf BTW, in this version it is even recommended to set up MCFG. So why should a BIOS vendor drop it? As I have stated in some mail yesterday there are actually 3 ECS access methods possible. For mmio config space accesses you have the choices that the translation is done either by CPU/NB or by the chipset. So if you do not enable MMIO config space access within CPU/NB, the CPU will not convert the config accesses to config cycles on the link. Which means that: - your tiny "random OS" should work as usual - you have no mmio config access to the northbridge functions. Said that, it seems obvious that the MMIO configuration requirements are just needed if the translation is done by the CPU/NB. Which makes somehow sense, because I think the CPU has to intercept somehow the MMIO traffic to decide whether config space should be accessed or not. And maybe the hardware designers had some reason to impose those requirements? So here comes one funny part out of that discussion. It seems that a workaround went into the kernel (commit 3320ad994afb2c44ad34b3b34c3c5cf0da297331) for a feature that is not yet switched on by the OS. Because Yinghai's patch is rejected. Or did I miss something? Did Andi rejected just the third patch and not the first two? Hm, ... (And obviously Dean Gaudet must have had a system where MSR 0xc0010058 was accordingly configured - by the BIOS or himself?) This shows just one thing. Code in this area needs more review and testing before it goes upstream. So maybe there is some problem with the "development process" for x86_64? > If they don't include MCFG, then the worst thing that can happen is that > the OS doesn't see the extended space. An OS that has chip-specific > workarounds can be aware that this chip is Special and enable MMCONFIG > and use it anyway. Why then not add code for this "fam 10h-chip" - to decide it is special and to set up the MmioConfigBase MSR in such a case? > In RFC-speak: > > Since this chip doesn't implement standards-conformant mmconfig, a BIOS > MUST NOT enable MCFG in ACPI. As a result, OSes that have chip-specific > workarounds, like Linux has, SHOULD detect it and use ad hoc code to > enable it anyway. #1: So if you all think that the new mmconfig stuff (done in the CPU/NB) is a crux, then make it right and double-check in the OS whether the MmioConfigBase MSR is set and clear it if you like! (And I can even imagine that you would send patches to do this ;-( And your statement is wrong again. If #1 is done. Then you should still have MCFG set up in the BIOS to tell the OS the config
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG
Usually one shouldn't reply to such mails. But I cannot resist. Because partially there was told such nonsense ... Of course the following is just my personal view. On 2007-09-13 20:54:41, H. Peter Anvin wrote: Andreas Herrmann wrote: On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? I'm not talking about Linux here. I'm talking about any random system software (which may or may not be Vista, and may nor may not even be an OS.) Are you serious? You are worried about Vista compatibility issues for new hardware? Here on LKML? I thought this is a Linux mailing list. But if this is your worry: Aren't you aware that most OSes have included patches in order to support this new hardware? Making use of the new pstates stuff is one example. And aren't you aware that even for proprietary OSes there are updates? But if that is not functioning for you why don't you just get rid of your proprietary hoax? If they advertise MCFG, then a random OS could try to use it, in accordance with the spec, without the workaround, with serious malfunction as a result. Have you looked into the BKDG of that CPU? You can download it here http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf BTW, in this version it is even recommended to set up MCFG. So why should a BIOS vendor drop it? As I have stated in some mail yesterday there are actually 3 ECS access methods possible. For mmio config space accesses you have the choices that the translation is done either by CPU/NB or by the chipset. So if you do not enable MMIO config space access within CPU/NB, the CPU will not convert the config accesses to config cycles on the link. Which means that: - your tiny random OS should work as usual - you have no mmio config access to the northbridge functions. Said that, it seems obvious that the MMIO configuration requirements are just needed if the translation is done by the CPU/NB. Which makes somehow sense, because I think the CPU has to intercept somehow the MMIO traffic to decide whether config space should be accessed or not. And maybe the hardware designers had some reason to impose those requirements? So here comes one funny part out of that discussion. It seems that a workaround went into the kernel (commit 3320ad994afb2c44ad34b3b34c3c5cf0da297331) for a feature that is not yet switched on by the OS. Because Yinghai's patch is rejected. Or did I miss something? Did Andi rejected just the third patch and not the first two? Hm, ... (And obviously Dean Gaudet must have had a system where MSR 0xc0010058 was accordingly configured - by the BIOS or himself?) This shows just one thing. Code in this area needs more review and testing before it goes upstream. So maybe there is some problem with the development process for x86_64? If they don't include MCFG, then the worst thing that can happen is that the OS doesn't see the extended space. An OS that has chip-specific workarounds can be aware that this chip is Special and enable MMCONFIG and use it anyway. Why then not add code for this fam 10h-chip - to decide it is special and to set up the MmioConfigBase MSR in such a case? In RFC-speak: Since this chip doesn't implement standards-conformant mmconfig, a BIOS MUST NOT enable MCFG in ACPI. As a result, OSes that have chip-specific workarounds, like Linux has, SHOULD detect it and use ad hoc code to enable it anyway. #1: So if you all think that the new mmconfig stuff (done in the CPU/NB) is a crux, then make it right and double-check in the OS whether the MmioConfigBase MSR is set and clear it if you like! (And I can even imagine that you would send patches to do this ;-( And your statement is wrong again. If #1 is done. Then you should still have MCFG set up in the BIOS to tell the OS the config space address range such that mmconfig can be done via the chipset. And some final notes: This stuff was long documented in some preliminary NDA specs. And some kernel developer(s) had access to it. So if it is such a big deal, why didn't they speak up earlier? Why I didn't speak up earlier? Because I have to admit that I didn't
[PATCH] v4l: fix build error for et61x251 driver
This fixes a kernel build problem and
should make it into 2.6.23, I think.
Regards,
Andreas
--
Get rid of some v4l1 remainders to avoid kernel build errors if
V4L1_COMPAT is not selected:
drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
declaration of to_video_device
Fix as suggested by Luca Risolia <[EMAIL PROTECTED]>
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/media/video/et61x251/et61x251_core.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/et61x251/et61x251_core.c
b/drivers/media/video/et61x251/et61x251_core.c
index 585bd1f..a3ee968 100644
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -715,7 +715,8 @@ static ssize_t et61x251_show_reg(struct class_device* cd,
char* buf)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -739,7 +740,8 @@ et61x251_store_reg(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -771,7 +773,8 @@ static ssize_t et61x251_show_val(struct class_device* cd,
char* buf)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -803,7 +806,8 @@ et61x251_store_val(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -839,7 +843,8 @@ static ssize_t et61x251_show_i2c_reg(struct class_device*
cd, char* buf)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -865,7 +870,8 @@ et61x251_store_i2c_reg(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -897,7 +903,8 @@ static ssize_t et61x251_show_i2c_val(struct class_device*
cd, char* buf)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
@@ -934,7 +941,8 @@ et61x251_store_i2c_val(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(_sysfs_lock);
return -ENODEV;
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: > Yinghai Lu wrote: > > > > BIOS guys also said that fam 10h need mmconfig via eax accessing, may > > need OS do sth, so it is safe to stay with MCFG entry for SB like > > mcp55... > > > > but latest kernel already have that workaround to make mmconfig via eax... > > > > This is actually a good point. Since the CPU vendor managed to > completely fuck up the operation of MMCONFIG itself on this CPU (it's a > *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent > that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually > work on this CPU for any system software which doesn't already know to > work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? > standards-complicant MMCONFIG isn't supported at all. And yes, it is complicated to follow your argumentation. Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 01:53:15PM +0200, Andi Kleen wrote: > On Thursday 13 September 2007 12:47, Greg KH wrote: > > On Thu, Sep 13, 2007 at 11:47:42AM +0200, Andi Kleen wrote: > > > On Thursday 13 September 2007 04:21, Yinghai Lu wrote: > > > > [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is > > > > used. > > > > > > > > reuse pci_cfg_space_size but skip check pci express and pci-x CAP ID. > > > > > > I just rejected a similar patch -- this should be done using MMCONFIG > > > > But what about for broken machines without the proper MMCONFIG entries? > > They still need a way to get access to this config space, > > If there are any devices that need it. IBS and PCI-E error handling > do, but they're quite obscure. > > Also so far we don't know of any Fam 10h systems without MMCONFIG > entries. Fam10h requires a new BIOS so it's reasonable to assume > that the new BIOSes will do better. IMHO support for all config space access methods should be added to the kernel. And it should be added at a central point. Not waiting for drivers to do it their own way if they need to use it. The more complicated/important question is how to decide which access method should be used for a device. (Something similar to the pci_mmcfg_fallback_slots stuff that exists already for K8 NB.) But that needs some more thinking. Here a summary wrt family 10h extended config space access methods. (Most of this stuff I verified with some patched kernels. I didn't eavesdropping on the physical links though ...) For family 10h we have 3 methods (1) "legacy" MMCONFIG access (via south bridge) (2) mmconfig access via CPU/NB (new with fam10h, using the new MMIO config base MSR) (3) CF8/CFC ECS access (new with fam10h, has to be enabled in the NB_CFG MSR) - If (1) is used and (2)+(3) are not configurred there is no way to access NB config space with mmconfig accesses. Which implies that NB ECS cannot be accessed. So you can only access NB standard config space via "legacy" CF8/CFC. This equals what we have with K8. => ECS is accessible just for external devices (not the NB ECS). - If (2) is used, mmconfig accesses are translated by CPU/NB. So this will result in (extended) config cycles on the link to the south bridge. This works for both NB config space and config space for normal PCI(e) devices. => ECS is accessible for all devices via that method. - And finally with (3) you can also access both NB config space and the config space of external devices. The CPU/NB does the translation and will also create (extended) config cycles here. => ECS is accessible for all devices via that method. (But of course not in the same "atomic" manner like with mmconfig.) Then we have different prereqs for those methods: - For (1) the ACPI stuff is required. - For (2) and (3) some MSRs have to be set up. Ah, yes in case I didn't mention that: ;-) Using (2) you haven't such a strict dependency on that ACPI stuff. Would be cool to disable MCFG at all and configure mmconfig just in the CPU, no? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 01:53:15PM +0200, Andi Kleen wrote: On Thursday 13 September 2007 12:47, Greg KH wrote: On Thu, Sep 13, 2007 at 11:47:42AM +0200, Andi Kleen wrote: On Thursday 13 September 2007 04:21, Yinghai Lu wrote: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used. reuse pci_cfg_space_size but skip check pci express and pci-x CAP ID. I just rejected a similar patch -- this should be done using MMCONFIG But what about for broken machines without the proper MMCONFIG entries? They still need a way to get access to this config space, If there are any devices that need it. IBS and PCI-E error handling do, but they're quite obscure. Also so far we don't know of any Fam 10h systems without MMCONFIG entries. Fam10h requires a new BIOS so it's reasonable to assume that the new BIOSes will do better. IMHO support for all config space access methods should be added to the kernel. And it should be added at a central point. Not waiting for drivers to do it their own way if they need to use it. The more complicated/important question is how to decide which access method should be used for a device. (Something similar to the pci_mmcfg_fallback_slots stuff that exists already for K8 NB.) But that needs some more thinking. Here a summary wrt family 10h extended config space access methods. (Most of this stuff I verified with some patched kernels. I didn't eavesdropping on the physical links though ...) For family 10h we have 3 methods (1) legacy MMCONFIG access (via south bridge) (2) mmconfig access via CPU/NB (new with fam10h, using the new MMIO config base MSR) (3) CF8/CFC ECS access (new with fam10h, has to be enabled in the NB_CFG MSR) - If (1) is used and (2)+(3) are not configurred there is no way to access NB config space with mmconfig accesses. Which implies that NB ECS cannot be accessed. So you can only access NB standard config space via legacy CF8/CFC. This equals what we have with K8. = ECS is accessible just for external devices (not the NB ECS). - If (2) is used, mmconfig accesses are translated by CPU/NB. So this will result in (extended) config cycles on the link to the south bridge. This works for both NB config space and config space for normal PCI(e) devices. = ECS is accessible for all devices via that method. - And finally with (3) you can also access both NB config space and the config space of external devices. The CPU/NB does the translation and will also create (extended) config cycles here. = ECS is accessible for all devices via that method. (But of course not in the same atomic manner like with mmconfig.) Then we have different prereqs for those methods: - For (1) the ACPI stuff is required. - For (2) and (3) some MSRs have to be set up. Ah, yes in case I didn't mention that: ;-) Using (2) you haven't such a strict dependency on that ACPI stuff. Would be cool to disable MCFG at all and configure mmconfig just in the CPU, no? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used
On Thu, Sep 13, 2007 at 10:20:56AM -0700, H. Peter Anvin wrote: Yinghai Lu wrote: BIOS guys also said that fam 10h need mmconfig via eax accessing, may need OS do sth, so it is safe to stay with MCFG entry for SB like mcp55... but latest kernel already have that workaround to make mmconfig via eax... This is actually a good point. Since the CPU vendor managed to completely fuck up the operation of MMCONFIG itself on this CPU (it's a *MEMORY REFERENCE*, guys!), it is actually to be expected and prudent that BIOS vendors will drop the MCFG entry. MMCONFIG doesn't actually work on this CPU for any system software which doesn't already know to work around this particular piece of severe braindamage; But wait, isn't it true that Vista is using MCFG? So, poor BIOS guys what should they do now? If you have a special problem here why not upgrading your Linux kernel? standards-complicant MMCONFIG isn't supported at all. And yes, it is complicated to follow your argumentation. Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] v4l: fix build error for et61x251 driver
This fixes a kernel build problem and
should make it into 2.6.23, I think.
Regards,
Andreas
--
Get rid of some v4l1 remainders to avoid kernel build errors if
V4L1_COMPAT is not selected:
drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_:
drivers/media/video/et61x251/et61x251_core.c:718: error: implicit
declaration of to_video_device
Fix as suggested by Luca Risolia [EMAIL PROTECTED]
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/media/video/et61x251/et61x251_core.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/et61x251/et61x251_core.c
b/drivers/media/video/et61x251/et61x251_core.c
index 585bd1f..a3ee968 100644
--- a/drivers/media/video/et61x251/et61x251_core.c
+++ b/drivers/media/video/et61x251/et61x251_core.c
@@ -715,7 +715,8 @@ static ssize_t et61x251_show_reg(struct class_device* cd,
char* buf)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -739,7 +740,8 @@ et61x251_store_reg(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -771,7 +773,8 @@ static ssize_t et61x251_show_val(struct class_device* cd,
char* buf)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -803,7 +806,8 @@ et61x251_store_val(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -839,7 +843,8 @@ static ssize_t et61x251_show_i2c_reg(struct class_device*
cd, char* buf)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -865,7 +870,8 @@ et61x251_store_i2c_reg(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -897,7 +903,8 @@ static ssize_t et61x251_show_i2c_val(struct class_device*
cd, char* buf)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
@@ -934,7 +941,8 @@ et61x251_store_i2c_val(struct class_device* cd, const char*
buf, size_t len)
if (mutex_lock_interruptible(et61x251_sysfs_lock))
return -ERESTARTSYS;
- cam = video_get_drvdata(to_video_device(cd));
+ cam = video_get_drvdata(container_of(cd, struct video_device,
+class_dev));
if (!cam) {
mutex_unlock(et61x251_sysfs_lock);
return -ENODEV;
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Request for Linux Kernel Mailing List archives
On Wed, Jun 20, 2007 at 12:38:48PM -0400, Hank Leininger wrote: > On Wed, 20 Jun 2007, H. Peter Anvin wrote: > >Bj�rn Steinbrink wrote: > >> > >>marc.info supports that. > >>http://marc.info/[EMAIL PROTECTED] > >Excellent! Didn't see that documented anywhere. > > You're right, it's not really. In fact very little is documented. > You'd have to discover it -- in the message view, the Message-ID is > actually a self-referential link using the above syntax. > > A few relevant points: > - - Such links never actually show you the corresponding message. Instead: > - If the message-id is unique, you are sent a 302 redirect to the > message using the normal MARC message URL (l=foo=123) > - If the message-id is not unique (such as crossposting, or deliberate > attempts to cause collisions) you'll be presented with a list of > messages, showing date, subject, author, and listname, to choose from. > - - MARC doesn't currently touch message bodies for spam-obfuscation > purposes, but it does for headers, specifically From: and Message-ID:. > When MARC generates message-id-based links, they are obfuscated. > But it can read in links formed either way. So, if you copy/paste the > target of a Message-ID: link out of MARC, it will look slightly > different than if you just made your own http://marc.info/[EMAIL PROTECTED], > but either form will work. > - - We don't use < > surrounding the message-id, but again, will accept > URLs formed either way. > - - We don't have Message-ID's for messages added before Dec, 2003. Thanks for that usefull info. Attached is a script containing a quick hack to enable look up of a message-id at MARC with mutt(ng). Posted to LKML just in case some other mutt(ng) user subscribed here finds it useful. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy show-mail.sh Description: Bourne shell script
Re: Request for Linux Kernel Mailing List archives
On Wed, Jun 20, 2007 at 12:38:48PM -0400, Hank Leininger wrote: On Wed, 20 Jun 2007, H. Peter Anvin wrote: Bj�rn Steinbrink wrote: marc.info supports that. http://marc.info/[EMAIL PROTECTED] Excellent! Didn't see that documented anywhere. You're right, it's not really. In fact very little is documented. You'd have to discover it -- in the message view, the Message-ID is actually a self-referential link using the above syntax. A few relevant points: - - Such links never actually show you the corresponding message. Instead: - If the message-id is unique, you are sent a 302 redirect to the message using the normal MARC message URL (l=foomsgid=123) - If the message-id is not unique (such as crossposting, or deliberate attempts to cause collisions) you'll be presented with a list of messages, showing date, subject, author, and listname, to choose from. - - MARC doesn't currently touch message bodies for spam-obfuscation purposes, but it does for headers, specifically From: and Message-ID:. When MARC generates message-id-based links, they are obfuscated. But it can read in links formed either way. So, if you copy/paste the target of a Message-ID: link out of MARC, it will look slightly different than if you just made your own http://marc.info/[EMAIL PROTECTED], but either form will work. - - We don't use surrounding the message-id, but again, will accept URLs formed either way. - - We don't have Message-ID's for messages added before Dec, 2003. Thanks for that usefull info. Attached is a script containing a quick hack to enable look up of a message-id at MARC with mutt(ng). Posted to LKML just in case some other mutt(ng) user subscribed here finds it useful. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy show-mail.sh Description: Bourne shell script
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Wed, Sep 05, 2007 at 01:05:25PM +0200, Arne Georg Gleditsch wrote: > "H. Peter Anvin" <[EMAIL PROTECTED]> writes: > > You're missing the point. How will the PCI bus transactions be > > different when using MMCONFIG versus your extended CF8 version? > > Conceivably this is useful if the IO hub does not support MMCONFIG > accesses. The AMD 8111 does not, as far as I can see. At least I > have an Opteron system where MMCONFIG is not supported, and I assume > it's because the 8111 doesn't provide it. I don't know if this is > going to be a realistic scenario for Barcelona systems. > > -- > Arne. Not sure how many AMD 8111 based systems are out there which are upgradeable to Barcelona. I guess the BIOS won't setup MCFG for systems with 8111/8131 because both lack ECS MMIO Base Address Register. (Because 8111 and 8131 are not Mode2-PCI-X and PCI-express capable.) So if such a board is upgradeable, the way to access extended config space of the northbridge functions is to use CF8/CFC ECS access. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Wed, Sep 05, 2007 at 06:58:58AM +0100, H. Peter Anvin wrote:
> Well, they don't add any functionality, do they?
They allow CF8/CFC to access ECS in cases where mmcfg is not working.
> As such, I would agree with Andi -- we only
> need one method which can (correctly) access the full configuration space,
Right, we need to be able to "correctly access the full config space".
> since it'll look the same on the bus anyway.
Sure, on the bus we should only see pci configuration requests in both
cases.
To summarize it:
- mmcfg needs support by BIOS ("PCI services in ACPI")
- CF8/CFC ECS access does not have that dependency
- For base configuration space access we already have two methods -
type 1 and mmcfg (type1 as fallback if there is no mmcfg).
- So what's the benefit in not allowing CF8/CFC ECS access ("extended type1")
if the hardware supports it and if mmcfg is not suitable?
One thing that comes out of that fruitless discussion:
For IBS Robert might have to implement CF8/CFC ECS access directly in the IBS
code, or in a new driver for ECS access of NB functions. Just to ensure that
IBS is working if there is no mmcfg. And this is kind of ugly.
Regards,
Andreas
--
Operating | AMD Saxony Limited Liability Company & Co. KG,
System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Research | Register Court Dresden: HRA 4896, General Partner authorized
Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
(OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Wed, Sep 05, 2007 at 06:58:58AM +0100, H. Peter Anvin wrote: Well, they don't add any functionality, do they? They allow CF8/CFC to access ECS in cases where mmcfg is not working. As such, I would agree with Andi -- we only need one method which can (correctly) access the full configuration space, Right, we need to be able to correctly access the full config space. since it'll look the same on the bus anyway. Sure, on the bus we should only see pci configuration requests in both cases. To summarize it: - mmcfg needs support by BIOS (PCI services in ACPI) - CF8/CFC ECS access does not have that dependency - For base configuration space access we already have two methods - type 1 and mmcfg (type1 as fallback if there is no mmcfg). - So what's the benefit in not allowing CF8/CFC ECS access (extended type1) if the hardware supports it and if mmcfg is not suitable? One thing that comes out of that fruitless discussion: For IBS Robert might have to implement CF8/CFC ECS access directly in the IBS code, or in a new driver for ECS access of NB functions. Just to ensure that IBS is working if there is no mmcfg. And this is kind of ugly. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Wed, Sep 05, 2007 at 01:05:25PM +0200, Arne Georg Gleditsch wrote: H. Peter Anvin [EMAIL PROTECTED] writes: You're missing the point. How will the PCI bus transactions be different when using MMCONFIG versus your extended CF8 version? Conceivably this is useful if the IO hub does not support MMCONFIG accesses. The AMD 8111 does not, as far as I can see. At least I have an Opteron system where MMCONFIG is not supported, and I assume it's because the 8111 doesn't provide it. I don't know if this is going to be a realistic scenario for Barcelona systems. -- Arne. Not sure how many AMD 8111 based systems are out there which are upgradeable to Barcelona. I guess the BIOS won't setup MCFG for systems with 8111/8131 because both lack ECS MMIO Base Address Register. (Because 8111 and 8131 are not Mode2-PCI-X and PCI-express capable.) So if such a board is upgradeable, the way to access extended config space of the northbridge functions is to use CF8/CFC ECS access. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 04:33:19AM -0700, Arjan van de Ven wrote: > On Mon, 3 Sep 2007 11:17:18 +0200 > "Andreas Herrmann" <[EMAIL PROTECTED]> wrote: > \> > > Do you see any other issues besides the naming of the bit? > > I wonder if we should key this off a PCI ID of the chipset rather than > the cpu id... I mean, how sure are you that all via chipsets connected > to the barcelona cpu will deal well? In general they should be able to deal with those accesses. They result in extended type 0/1 configuration cycles which are defined already in HT I/O Link Spec 1.10. So if unexpectedly problems arise then it is time to add a pci-quirk. But at the moment there is no need for further discussion on this subject because Andi refuses to add support for Barcelona CF8/CFC ECS access. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 12:15:03PM +0200, Andi Kleen wrote: > > > But it is needed for some devices for full functionality. > > Examples? I can only think of PCI express error reporting, which > few drivers implement anyways and isn't really a show stopper > if it doesn't work. Besides I would be surprised if it even works > on the cheap desktop boards which have MCFG less BIOS. Sure, AER is one example. I don't see why all other stuff in ECS is not worth reading or writing. And I am not sure whether all server boards set up MCFG in the correct way. > > E.g. for perfmon (family 0x10/extended inerrupts) extended config space > > access is a prerequisite. > > How so? E.g. access to the IBS control register needs ECS access on Barcelona. I guess we have to wait until Robert sends his patches which contain all details. > > > > IMHO it is best to try to use MMCONFIG if it's working and to use > > a fallback (e.g. CF8 ECS access for family 0x10) if available. > > We only put in workarounds if there is a serious problem otherwise (e.g. not > booting etc.). I just don't see this here. The serious problem is you can't access PCI ECS if the BIOS does not take care to (correctly) set up MCFG. And unfortunately this is too often the case. See for instance Robert Hancock's patch http://lkml.org/lkml/2007/5/30/2 to enable MMCONFIG access in certain cases where BIOS did not correctly set up MCFG. Why are people working on such stuff if it is not serious enough? Barcelona just adds another way to access PCI ECS (besides MMCONFIG) and I can't understand why this shouldn't be supported by Linux. Do you have any suggestion how else to add support for PCI ECS access via IO instructions for Barcelona? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 01:31:57AM -0700, Arjan van de Ven wrote: > On Mon, 03 Sep 2007 10:17:39 +0200 > "Robert Richter" <[EMAIL PROTECTED]> wrote: > > > This patch implements PCI extended configuration space access for > > AMD's Barcelona CPUs. It extends the method using CF8/CFC IO > > addresses. An x86 capability bit has been introduced that is set for > > CPUs supporting PCI extended config space accesses. > > > > > No offence but this feels a bit wrong to me. > > PCI is sort of more a chipset property than a cpu property (I realize > that this boundary is changing of course). > > I'd like to ask you to at least rename some of the feature bits to > indicate that the extended config space is for the IO access method; > after all Linux already supports the MMIO method for accessing extended > config space since a really long time; not marking the feature bit to > indicate it's the IO method is going to be extremely confusing and > cause bugs I bet. Hmm, yes the naming of the CPU capability bit seems wrong. Guess, Robert will fix it. > (we probably need a global function that drivers can use to find out of > extended config space is accessible; however that for sure isn't a CPU > capability bit. IMHO this is already available. Just check pci_dev->cfg_size which is 256 if PCI ECS access is not possible (see pci_cfg_space_size()). > However the current naming etc sort of makes me fear > drivers will abuse this thing while thinking it's the right API) Do you see any other issues besides the naming of the bit? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Sat, Sep 01, 2007 at 12:11:52PM +0200, Andi Kleen wrote: > On Thursday 30 August 2007 19:43:14 Robert Richter wrote: > > This patch implements PCI extended configuration space access for > > AMD's Barcelona CPUs. It extends the method using CF8/CFC IO > > addresses. An x86 capability bit has been introduced that is set for > > CPUs supporting PCI extended config space accesses. > > We shouldn't need this because extended config space should work > here and Linux should use it > (especially after we added the ugly Barcelona workaround into that code) This patch is needed for all buggy BIOSes that don't correctly set up MCFG. > The only exception would be if the user disables MMCONFIG in CONFIG, but > that's > their own fault then. No, as you stated yourself there are two exceptions. And the more serious one is the BIOS issue. > Ok there might be buggy BIOS around with no or no usable MCFG table, but since > extended config space is not really a critical feature that's not a big issue. Not sure why you assume extended config space (ECS) is not critical. Ok, for a lot of stuff it does not matter. But it is needed for some devices for full functionality. E.g. for perfmon (family 0x10/extended inerrupts) extended config space access is a prerequisite. > So I don't think we want this special case code at all and should > just rely on MMCONFIG. Rely on something unreliable (due to buggy/incomplete BIOS)? I don't think we should do this. IMHO it is best to try to use MMCONFIG if it's working and to use a fallback (e.g. CF8 ECS access for family 0x10) if available. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Sat, Sep 01, 2007 at 12:11:52PM +0200, Andi Kleen wrote: On Thursday 30 August 2007 19:43:14 Robert Richter wrote: This patch implements PCI extended configuration space access for AMD's Barcelona CPUs. It extends the method using CF8/CFC IO addresses. An x86 capability bit has been introduced that is set for CPUs supporting PCI extended config space accesses. We shouldn't need this because extended config space should work here and Linux should use it (especially after we added the ugly Barcelona workaround into that code) This patch is needed for all buggy BIOSes that don't correctly set up MCFG. The only exception would be if the user disables MMCONFIG in CONFIG, but that's their own fault then. No, as you stated yourself there are two exceptions. And the more serious one is the BIOS issue. Ok there might be buggy BIOS around with no or no usable MCFG table, but since extended config space is not really a critical feature that's not a big issue. Not sure why you assume extended config space (ECS) is not critical. Ok, for a lot of stuff it does not matter. But it is needed for some devices for full functionality. E.g. for perfmon (family 0x10/extended inerrupts) extended config space access is a prerequisite. So I don't think we want this special case code at all and should just rely on MMCONFIG. Rely on something unreliable (due to buggy/incomplete BIOS)? I don't think we should do this. IMHO it is best to try to use MMCONFIG if it's working and to use a fallback (e.g. CF8 ECS access for family 0x10) if available. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 01:31:57AM -0700, Arjan van de Ven wrote: On Mon, 03 Sep 2007 10:17:39 +0200 Robert Richter [EMAIL PROTECTED] wrote: This patch implements PCI extended configuration space access for AMD's Barcelona CPUs. It extends the method using CF8/CFC IO addresses. An x86 capability bit has been introduced that is set for CPUs supporting PCI extended config space accesses. No offence but this feels a bit wrong to me. PCI is sort of more a chipset property than a cpu property (I realize that this boundary is changing of course). I'd like to ask you to at least rename some of the feature bits to indicate that the extended config space is for the IO access method; after all Linux already supports the MMIO method for accessing extended config space since a really long time; not marking the feature bit to indicate it's the IO method is going to be extremely confusing and cause bugs I bet. Hmm, yes the naming of the CPU capability bit seems wrong. Guess, Robert will fix it. (we probably need a global function that drivers can use to find out of extended config space is accessible; however that for sure isn't a CPU capability bit. IMHO this is already available. Just check pci_dev-cfg_size which is 256 if PCI ECS access is not possible (see pci_cfg_space_size()). However the current naming etc sort of makes me fear drivers will abuse this thing while thinking it's the right API) Do you see any other issues besides the naming of the bit? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 12:15:03PM +0200, Andi Kleen wrote: But it is needed for some devices for full functionality. Examples? I can only think of PCI express error reporting, which few drivers implement anyways and isn't really a show stopper if it doesn't work. Besides I would be surprised if it even works on the cheap desktop boards which have MCFG less BIOS. Sure, AER is one example. I don't see why all other stuff in ECS is not worth reading or writing. And I am not sure whether all server boards set up MCFG in the correct way. E.g. for perfmon (family 0x10/extended inerrupts) extended config space access is a prerequisite. How so? E.g. access to the IBS control register needs ECS access on Barcelona. I guess we have to wait until Robert sends his patches which contain all details. IMHO it is best to try to use MMCONFIG if it's working and to use a fallback (e.g. CF8 ECS access for family 0x10) if available. We only put in workarounds if there is a serious problem otherwise (e.g. not booting etc.). I just don't see this here. The serious problem is you can't access PCI ECS if the BIOS does not take care to (correctly) set up MCFG. And unfortunately this is too often the case. See for instance Robert Hancock's patch http://lkml.org/lkml/2007/5/30/2 to enable MMCONFIG access in certain cases where BIOS did not correctly set up MCFG. Why are people working on such stuff if it is not serious enough? Barcelona just adds another way to access PCI ECS (besides MMCONFIG) and I can't understand why this shouldn't be supported by Linux. Do you have any suggestion how else to add support for PCI ECS access via IO instructions for Barcelona? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [patch 3/5] x86: Add PCI extended config space access for AMD Barcelona
On Mon, Sep 03, 2007 at 04:33:19AM -0700, Arjan van de Ven wrote: On Mon, 3 Sep 2007 11:17:18 +0200 Andreas Herrmann [EMAIL PROTECTED] wrote: \ Do you see any other issues besides the naming of the bit? I wonder if we should key this off a PCI ID of the chipset rather than the cpu id... I mean, how sure are you that all via chipsets connected to the barcelona cpu will deal well? In general they should be able to deal with those accesses. They result in extended type 0/1 configuration cycles which are defined already in HT I/O Link Spec 1.10. So if unexpectedly problems arise then it is time to add a pci-quirk. But at the moment there is no need for further discussion on this subject because Andi refuses to add support for Barcelona CF8/CFC ECS access. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [17/58] i386: Add L3 cache support to AMD CPUID4 emulation
I think, Joachim's patch (sent to [EMAIL PROTECTED] on June 14) should
be added as well. I have attached his patch below.
Regards,
Andreas
--
Operating | AMD Saxony Limited Liability Company & Co. KG,
System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Research | Register Court Dresden: HRA 4896, General Partner authorized
Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
(OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
--
This will allow the size field to be reported for all values instead of a
handful and also fills the shard_cpu_map with meaning full value.
Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]>
Index: kernel/arch/i386/kernel/cpu/intel_cacheinfo.c
===
--- kernel.orig/arch/i386/kernel/cpu/intel_cacheinfo.c
+++ kernel/arch/i386/kernel/cpu/intel_cacheinfo.c
@@ -224,12 +224,7 @@ static void __cpuinit amd_cpuid4(int lea
assoc = l3.assoc;
line_size = l3.line_size;
lines_per_tag = l3.lines_per_tag;
- switch (l3.size_encoded) {
- case 4: size_in_kb = 2 * 1024; break;
- case 8: size_in_kb = 4 * 1024; break;
- case 12: size_in_kb = 6 * 1024; break;
- default: size_in_kb = 0; break;
- }
+ size_in_kb = l3.size_encoded * 512;
break;
default:
return;
@@ -238,7 +233,10 @@ static void __cpuinit amd_cpuid4(int lea
eax->split.is_self_initializing = 1;
eax->split.type = types[leaf];
eax->split.level = levels[leaf];
- eax->split.num_threads_sharing = 0;
+ if (leaf == 3)
+ eax->split.num_threads_sharing = current_cpu_data.x86_max_cores
- 1;
+ else
+ eax->split.num_threads_sharing = 0;
eax->split.num_cores_on_die = current_cpu_data.x86_max_cores - 1;
___
patches mailing list
[EMAIL PROTECTED]
https://www.x86-64.org/mailman/listinfo/patches
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [17/58] i386: Add L3 cache support to AMD CPUID4 emulation
On Thu, Jul 19, 2007 at 11:55:02AM +0200, Andi Kleen wrote:
>
> With that an L3 cache is correctly reported in the cache information in /sys
>
> With fixes from Andreas Herrmann and Dean Gaudet
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
>
> ---
> arch/i386/kernel/cpu/intel_cacheinfo.c | 74
> -
> arch/x86_64/kernel/setup.c |7 ++-
> 2 files changed, 60 insertions(+), 21 deletions(-)
Reporting of L3 cache information should also be enabled in 32bit mode.
Regards,
Andreas
--
Enable reporting of L3 cache info in 32 bit mode for family 0x10.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/cpu/amd.c b/arch/i386/kernel/cpu/amd.c
index 6f47eee..815a5f0 100644
--- a/arch/i386/kernel/cpu/amd.c
+++ b/arch/i386/kernel/cpu/amd.c
@@ -272,8 +272,12 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
}
#endif
- if (cpuid_eax(0x8000) >= 0x8006)
- num_cache_leaves = 3;
+ if (cpuid_eax(0x8000) >= 0x8006) {
+ if ((c->x86 == 0x10) && (cpuid_edx(0x8006) & 0xf000))
+ num_cache_leaves = 4;
+ else
+ num_cache_leaves = 3;
+ }
if (amd_apic_timer_broken())
set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c->x86_capability);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [17/58] i386: Add L3 cache support to AMD CPUID4 emulation
On Thu, Jul 19, 2007 at 11:55:02AM +0200, Andi Kleen wrote:
With that an L3 cache is correctly reported in the cache information in /sys
With fixes from Andreas Herrmann and Dean Gaudet
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/intel_cacheinfo.c | 74
-
arch/x86_64/kernel/setup.c |7 ++-
2 files changed, 60 insertions(+), 21 deletions(-)
Reporting of L3 cache information should also be enabled in 32bit mode.
Regards,
Andreas
--
Enable reporting of L3 cache info in 32 bit mode for family 0x10.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/cpu/amd.c b/arch/i386/kernel/cpu/amd.c
index 6f47eee..815a5f0 100644
--- a/arch/i386/kernel/cpu/amd.c
+++ b/arch/i386/kernel/cpu/amd.c
@@ -272,8 +272,12 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
}
#endif
- if (cpuid_eax(0x8000) = 0x8006)
- num_cache_leaves = 3;
+ if (cpuid_eax(0x8000) = 0x8006) {
+ if ((c-x86 == 0x10) (cpuid_edx(0x8006) 0xf000))
+ num_cache_leaves = 4;
+ else
+ num_cache_leaves = 3;
+ }
if (amd_apic_timer_broken())
set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c-x86_capability);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [17/58] i386: Add L3 cache support to AMD CPUID4 emulation
I think, Joachim's patch (sent to [EMAIL PROTECTED] on June 14) should
be added as well. I have attached his patch below.
Regards,
Andreas
--
Operating | AMD Saxony Limited Liability Company Co. KG,
System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Research | Register Court Dresden: HRA 4896, General Partner authorized
Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
(OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
--
This will allow the size field to be reported for all values instead of a
handful and also fills the shard_cpu_map with meaning full value.
Signed-off-by: Joachim Deguara [EMAIL PROTECTED]
Index: kernel/arch/i386/kernel/cpu/intel_cacheinfo.c
===
--- kernel.orig/arch/i386/kernel/cpu/intel_cacheinfo.c
+++ kernel/arch/i386/kernel/cpu/intel_cacheinfo.c
@@ -224,12 +224,7 @@ static void __cpuinit amd_cpuid4(int lea
assoc = l3.assoc;
line_size = l3.line_size;
lines_per_tag = l3.lines_per_tag;
- switch (l3.size_encoded) {
- case 4: size_in_kb = 2 * 1024; break;
- case 8: size_in_kb = 4 * 1024; break;
- case 12: size_in_kb = 6 * 1024; break;
- default: size_in_kb = 0; break;
- }
+ size_in_kb = l3.size_encoded * 512;
break;
default:
return;
@@ -238,7 +233,10 @@ static void __cpuinit amd_cpuid4(int lea
eax-split.is_self_initializing = 1;
eax-split.type = types[leaf];
eax-split.level = levels[leaf];
- eax-split.num_threads_sharing = 0;
+ if (leaf == 3)
+ eax-split.num_threads_sharing = current_cpu_data.x86_max_cores
- 1;
+ else
+ eax-split.num_threads_sharing = 0;
eax-split.num_cores_on_die = current_cpu_data.x86_max_cores - 1;
___
patches mailing list
[EMAIL PROTECTED]
https://www.x86-64.org/mailman/listinfo/patches
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 12:03:19PM -0300, Mauro Carvalho Chehab wrote: > Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu: > > On Jun 22 2007 15:46, Andreas Herrmann wrote: > > >Hi, > > > > > >I am not sure whether it is related or not > > >But if you select USB as module but build your v4l_usb driver > > >into the kernel you also get compile errors. > > >Attached is a patch which will prevent this by changing the menuconfig > > >from bool to tristate. > > > > A config option that is not referenced in the Makefile... > > should it really be a tristate? In my opinion, changing it > > to tristate is just a workaround, but I don't know kconfig > > well enough to make bool Do The Right Thing in these situations myself :( > > If USB is built as a module, the V4L USB modules should also be built as > a module. Otherwise, you will have compile errors, since some required > symbols on the drivers won't be linked into the kernel. > Sure. And the patch should prevent user selection of such a broken kernel configuration. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/12] acpi: select ACPI_EC for THINKPAD_ACPI
On Tue, Jun 19, 2007 at 09:57:44PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 20 Jun 2007, Andreas Herrmann wrote: > > Fix kernel build problem: > > > > thinkpad_acpi.c:(.text+0x7486a): undefined reference to `ec_write' > > > > (as THINKPAD_ACPI depends on ACPI_EC) > > > > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > > --- > > drivers/misc/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > > index 2f2fbff..72774c9 100644 > > --- a/drivers/misc/Kconfig > > +++ b/drivers/misc/Kconfig > > @@ -139,6 +139,7 @@ config SONYPI_COMPAT > > config THINKPAD_ACPI > > tristate "ThinkPad ACPI Laptop Extras" > > depends on X86 && ACPI > > + select ACPI_EC > > select BACKLIGHT_CLASS_DEVICE > > select HWMON > > ---help--- > > Acked-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > Well, this one shouldn't be applied. The problem is better fixed in arch/x86_64/Kconfig. BTW, the above patch would lead to kconfig warnings on non x86-architectures. A proper version would be to add "select ACPI_EC if X86". Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Thu, Jun 21, 2007 at 08:36:15PM +0200, Andreas Herrmann wrote: > On Wed, Jun 20, 2007 at 11:25:48AM -0700, Ravikiran G Thirumalai wrote: > > On Wed, Jun 20, 2007 at 09:36:30AM -0400, Len Brown wrote: > > > > > > The underlying problem is that Kconfig doesn't support using select > > > on targets which themselves have dependencies. > > > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > > > > > > diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig > > > index 5ce9443..e9d7767 100644 > > > --- a/arch/x86_64/Kconfig > > > +++ b/arch/x86_64/Kconfig > > > @@ -364,9 +364,9 @@ config NODES_SHIFT > > > config X86_64_ACPI_NUMA > > > bool "ACPI NUMA detection" > > > depends on NUMA > > > - select ACPI > > > + depends on ACPI > > > select PCI > > > - select ACPI_NUMA > > > + depends on ACPI_NUMA > > > default y > > > help > > >Enable ACPI SRAT based node topology detection. > > > - > > > > > > > > Paper over 'select' inadequacies. > > > > Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]> > > > > Index: linux-2.6.22-rc5/arch/x86_64/Kconfig > > === > > --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 > > 16:02:19.571323415 -0700 > > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig2007-06-20 11:34:29.845354250 > > -0700 > > @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA > > depends on NUMA > > select ACPI > > select PCI > > + select PM > > select ACPI_NUMA > > default y > > help > > Yep, this one-liner solves all acpi related compile errors/warnings > that I've reported. > > Additional it resolves anoter problem that results from > dependencies between CONFIG_PNP and CONFIG_ACPI. > Andi, are you going to apply Ravikiran's patch? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 03:51:34PM +0200, Jan Engelhardt wrote: > > On Jun 22 2007 15:46, Andreas Herrmann wrote: > >Hi, > > > >I am not sure whether it is related or not > >But if you select USB as module but build your v4l_usb driver > >into the kernel you also get compile errors. > >Attached is a patch which will prevent this by changing the menuconfig > >from bool to tristate. > > A config option that is not referenced in the Makefile... > should it really be a tristate? In my opinion, changing it > to tristate is just a workaround, but I don't know kconfig > well enough to make bool Do The Right Thing in these situations myself :( dito Same problem occurred with "menuconfig NET_PCMCIA". See http://marc.info/?l=linux-kernel=118244569131373 Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] DLM: fix kconfig dependency
Avoid kernel build error (as DLM depends on SYSFS) LD vmlinux fs/built-in.o: In function `dlm_lockspace_init': : undefined reference to `kernel_subsys' fs/built-in.o: In function `configfs_init': mount.c:(.init.text+0xef4): undefined reference to `kernel_subsys' Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig index 69a9469..c0e4c59 100644 --- a/fs/dlm/Kconfig +++ b/fs/dlm/Kconfig @@ -1,5 +1,5 @@ menu "Distributed Lock Manager" - depends on EXPERIMENTAL && INET + depends on EXPERIMENTAL && INET && SYSFS config DLM tristate "Distributed Lock Manager (DLM)" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] usbnet: fix kconfig for usbnet drivers
Fix kernel build error: drivers/built-in.o: In function `usbnet_set_settings': : undefined reference to `mii_ethtool_sset' drivers/built-in.o: In function `usbnet_get_settings': : undefined reference to `mii_ethtool_gset' drivers/built-in.o: In function `usbnet_get_link': : undefined reference to `mii_link_ok' drivers/built-in.o: In function `usbnet_nway_reset': : undefined reference to `mii_nway_restart' This occurs when an USBNET device is built-in but MII is selected as module. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 8dc09a3..5a38fa2 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -68,6 +68,7 @@ config USB_KAWETH config USB_PEGASUS tristate "USB Pegasus/Pegasus-II based ethernet device support" + select NET_ETHERNET select MII ---help--- Say Y here if you know you have Pegasus or Pegasus-II based adapter. @@ -84,6 +85,7 @@ config USB_PEGASUS config USB_RTL8150 tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" depends on EXPERIMENTAL + select NET_ETHERNET select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. @@ -93,13 +95,8 @@ config USB_RTL8150 To compile this driver as a module, choose M here: the module will be called rtl8150. -config USB_USBNET_MII - tristate - default n - config USB_USBNET tristate "Multi-purpose USB Networking Framework" - select MII if USB_USBNET_MII != n ---help--- This driver supports several kinds of network links over USB, with "minidrivers" built around a common network driver core @@ -135,7 +132,7 @@ config USB_NET_AX8817X tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters" depends on USB_USBNET && NET_ETHERNET select CRC32 - select USB_USBNET_MII + select MII default y help This option adds support for ASIX AX88xxx based USB 2.0 @@ -190,7 +187,8 @@ config USB_NET_DM9601 tristate "Davicom DM9601 based USB 1.1 10/100 ethernet devices" depends on USB_USBNET select CRC32 - select USB_USBNET_MII + select NET_ETHERNET + select MII help This option adds support for Davicom DM9601 based USB 1.1 10/100 Ethernet adapters. @@ -225,7 +223,8 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate "MosChip MCS7830 based Ethernet adapters" depends on USB_USBNET - select USB_USBNET_MII + select NET_ETHERNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 10:22:46AM -0300, Mauro Carvalho Chehab wrote: > Hi Roman, > > Several instabilities on Kconfig started to happen after replacing > Kconfig menus to use menuconfig, as this one, reported by Oliver: > > Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu: > > Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster: > > > Right, but IMHO this issue is typical for a problem with the Kconfig > > > definitions of this module. > > > > > > I'll set USB devs as Cc: therefore. > > > > The Kconfig there is incomplete. > > Mauro, please apply. > > > > Regards > > Oliver > > Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]> > > > > --- a/drivers/media/video/zc0301/Kconfig2007-06-21 > > 13:44:14.0 +0200 > > +++ b/drivers/media/video/zc0301/Kconfig2007-06-21 > > 13:44:33.0 +0200 > > @@ -1,6 +1,6 @@ > > config USB_ZC0301 > > tristate "USB ZC0301[P] Image Processor and Control Chip support" > > - depends on VIDEO_V4L1 > > + depends on VIDEO_V4L1 && USB > > ---help--- > > Say Y here if you want support for cameras based on the ZC0301 or > > ZC0301P Image Processors and Control Chips. > > > > In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS, > that depends, in turn, on USB. So, if USB is not selected, > V4L_USB_DRIVERS should be unselected, unselecting zc0301. > > Unfortunately, the Kernel building system is not properly handling it. > > This is the (snipped) media/video/Kconfig: > > menuconfig V4L_USB_DRIVERS > bool "V4L USB devices" > depends on USB > default y > > if V4L_USB_DRIVERS > > source "drivers/media/video/pvrusb2/Kconfig" > > > > source "drivers/media/video/zc0301/Kconfig" > > > > endif # V4L_USB_DRIVERS > > -- > Cheers, > Mauro > Hi, I am not sure whether it is related or not But if you select USB as module but build your v4l_usb driver into the kernel you also get compile errors. Attached is a patch which will prevent this by changing the menuconfig from bool to tristate. Regards, Andreas -- Correct Kconfig to avoid compile errors like drivers/built-in.o: In function `sn9c102_usb_disconnect': sn9c102_core.c:(.text+0x8d840): undefined reference to `usb_get_dev' Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4cca551..4754d98 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC # menuconfig V4L_USB_DRIVERS - bool "V4L USB devices" + tristate "V4L USB devices" depends on USB default y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 10:22:46AM -0300, Mauro Carvalho Chehab wrote: Hi Roman, Several instabilities on Kconfig started to happen after replacing Kconfig menus to use menuconfig, as this one, reported by Oliver: Em Qui, 2007-06-21 às 13:50 +0200, Oliver Neukum escreveu: Am Donnerstag, 21. Juni 2007 schrieb Toralf Förster: Right, but IMHO this issue is typical for a problem with the Kconfig definitions of this module. I'll set USB devs as Cc: therefore. The Kconfig there is incomplete. Mauro, please apply. Regards Oliver Signed-off-by: Oliver Neukum [EMAIL PROTECTED] --- a/drivers/media/video/zc0301/Kconfig2007-06-21 13:44:14.0 +0200 +++ b/drivers/media/video/zc0301/Kconfig2007-06-21 13:44:33.0 +0200 @@ -1,6 +1,6 @@ config USB_ZC0301 tristate USB ZC0301[P] Image Processor and Control Chip support - depends on VIDEO_V4L1 + depends on VIDEO_V4L1 USB ---help--- Say Y here if you want support for cameras based on the ZC0301 or ZC0301P Image Processors and Control Chips. In this specific case, all V4L USB drivers depends on V4L_USB_DRIVERS, that depends, in turn, on USB. So, if USB is not selected, V4L_USB_DRIVERS should be unselected, unselecting zc0301. Unfortunately, the Kernel building system is not properly handling it. This is the (snipped) media/video/Kconfig: menuconfig V4L_USB_DRIVERS bool V4L USB devices depends on USB default y if V4L_USB_DRIVERS source drivers/media/video/pvrusb2/Kconfig snip/ source drivers/media/video/zc0301/Kconfig snip/ endif # V4L_USB_DRIVERS -- Cheers, Mauro Hi, I am not sure whether it is related or not But if you select USB as module but build your v4l_usb driver into the kernel you also get compile errors. Attached is a patch which will prevent this by changing the menuconfig from bool to tristate. Regards, Andreas -- Correct Kconfig to avoid compile errors like drivers/built-in.o: In function `sn9c102_usb_disconnect': sn9c102_core.c:(.text+0x8d840): undefined reference to `usb_get_dev' Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 4cca551..4754d98 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -687,7 +687,7 @@ config VIDEO_CAFE_CCIC # menuconfig V4L_USB_DRIVERS - bool V4L USB devices + tristate V4L USB devices depends on USB default y - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] usbnet: fix kconfig for usbnet drivers
Fix kernel build error: drivers/built-in.o: In function `usbnet_set_settings': : undefined reference to `mii_ethtool_sset' drivers/built-in.o: In function `usbnet_get_settings': : undefined reference to `mii_ethtool_gset' drivers/built-in.o: In function `usbnet_get_link': : undefined reference to `mii_link_ok' drivers/built-in.o: In function `usbnet_nway_reset': : undefined reference to `mii_nway_restart' This occurs when an USBNET device is built-in but MII is selected as module. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 8dc09a3..5a38fa2 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -68,6 +68,7 @@ config USB_KAWETH config USB_PEGASUS tristate USB Pegasus/Pegasus-II based ethernet device support + select NET_ETHERNET select MII ---help--- Say Y here if you know you have Pegasus or Pegasus-II based adapter. @@ -84,6 +85,7 @@ config USB_PEGASUS config USB_RTL8150 tristate USB RTL8150 based ethernet device support (EXPERIMENTAL) depends on EXPERIMENTAL + select NET_ETHERNET select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. @@ -93,13 +95,8 @@ config USB_RTL8150 To compile this driver as a module, choose M here: the module will be called rtl8150. -config USB_USBNET_MII - tristate - default n - config USB_USBNET tristate Multi-purpose USB Networking Framework - select MII if USB_USBNET_MII != n ---help--- This driver supports several kinds of network links over USB, with minidrivers built around a common network driver core @@ -135,7 +132,7 @@ config USB_NET_AX8817X tristate ASIX AX88xxx Based USB 2.0 Ethernet Adapters depends on USB_USBNET NET_ETHERNET select CRC32 - select USB_USBNET_MII + select MII default y help This option adds support for ASIX AX88xxx based USB 2.0 @@ -190,7 +187,8 @@ config USB_NET_DM9601 tristate Davicom DM9601 based USB 1.1 10/100 ethernet devices depends on USB_USBNET select CRC32 - select USB_USBNET_MII + select NET_ETHERNET + select MII help This option adds support for Davicom DM9601 based USB 1.1 10/100 Ethernet adapters. @@ -225,7 +223,8 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate MosChip MCS7830 based Ethernet adapters depends on USB_USBNET - select USB_USBNET_MII + select NET_ETHERNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Thu, Jun 21, 2007 at 08:36:15PM +0200, Andreas Herrmann wrote: On Wed, Jun 20, 2007 at 11:25:48AM -0700, Ravikiran G Thirumalai wrote: On Wed, Jun 20, 2007 at 09:36:30AM -0400, Len Brown wrote: snip The underlying problem is that Kconfig doesn't support using select on targets which themselves have dependencies. Signed-off-by: Len Brown [EMAIL PROTECTED] diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 5ce9443..e9d7767 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -364,9 +364,9 @@ config NODES_SHIFT config X86_64_ACPI_NUMA bool ACPI NUMA detection depends on NUMA - select ACPI + depends on ACPI select PCI - select ACPI_NUMA + depends on ACPI_NUMA default y help Enable ACPI SRAT based node topology detection. - snip Paper over 'select' inadequacies. Signed-off-by: Ravikiran Thirumalai [EMAIL PROTECTED] Index: linux-2.6.22-rc5/arch/x86_64/Kconfig === --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 16:02:19.571323415 -0700 +++ linux-2.6.22-rc5/arch/x86_64/Kconfig2007-06-20 11:34:29.845354250 -0700 @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA depends on NUMA select ACPI select PCI + select PM select ACPI_NUMA default y help Yep, this one-liner solves all acpi related compile errors/warnings that I've reported. Additional it resolves anoter problem that results from dependencies between CONFIG_PNP and CONFIG_ACPI. Andi, are you going to apply Ravikiran's patch? Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/12] acpi: select ACPI_EC for THINKPAD_ACPI
On Tue, Jun 19, 2007 at 09:57:44PM -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Jun 2007, Andreas Herrmann wrote: Fix kernel build problem: thinkpad_acpi.c:(.text+0x7486a): undefined reference to `ec_write' (as THINKPAD_ACPI depends on ACPI_EC) Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2f2fbff..72774c9 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -139,6 +139,7 @@ config SONYPI_COMPAT config THINKPAD_ACPI tristate ThinkPad ACPI Laptop Extras depends on X86 ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE select HWMON ---help--- Acked-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] Well, this one shouldn't be applied. The problem is better fixed in arch/x86_64/Kconfig. BTW, the above patch would lead to kconfig warnings on non x86-architectures. A proper version would be to add select ACPI_EC if X86. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] DLM: fix kconfig dependency
Avoid kernel build error (as DLM depends on SYSFS) LD vmlinux fs/built-in.o: In function `dlm_lockspace_init': : undefined reference to `kernel_subsys' fs/built-in.o: In function `configfs_init': mount.c:(.init.text+0xef4): undefined reference to `kernel_subsys' Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] diff --git a/fs/dlm/Kconfig b/fs/dlm/Kconfig index 69a9469..c0e4c59 100644 --- a/fs/dlm/Kconfig +++ b/fs/dlm/Kconfig @@ -1,5 +1,5 @@ menu Distributed Lock Manager - depends on EXPERIMENTAL INET + depends on EXPERIMENTAL INET SYSFS config DLM tristate Distributed Lock Manager (DLM) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 03:51:34PM +0200, Jan Engelhardt wrote: On Jun 22 2007 15:46, Andreas Herrmann wrote: Hi, I am not sure whether it is related or not But if you select USB as module but build your v4l_usb driver into the kernel you also get compile errors. Attached is a patch which will prevent this by changing the menuconfig from bool to tristate. A config option that is not referenced in the Makefile... should it really be a tristate? In my opinion, changing it to tristate is just a workaround, but I don't know kconfig well enough to make bool Do The Right Thing in these situations myself :( dito Same problem occurred with menuconfig NET_PCMCIA. See http://marc.info/?l=linux-kernelm=118244569131373 Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig troubles when using menuconfig - Was: [patch]Re: [linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Fri, Jun 22, 2007 at 12:03:19PM -0300, Mauro Carvalho Chehab wrote: Em Sex, 2007-06-22 às 15:51 +0200, Jan Engelhardt escreveu: On Jun 22 2007 15:46, Andreas Herrmann wrote: Hi, I am not sure whether it is related or not But if you select USB as module but build your v4l_usb driver into the kernel you also get compile errors. Attached is a patch which will prevent this by changing the menuconfig from bool to tristate. A config option that is not referenced in the Makefile... should it really be a tristate? In my opinion, changing it to tristate is just a workaround, but I don't know kconfig well enough to make bool Do The Right Thing in these situations myself :( If USB is built as a module, the V4L USB modules should also be built as a module. Otherwise, you will have compile errors, since some required symbols on the drivers won't be linked into the kernel. Sure. And the patch should prevent user selection of such a broken kernel configuration. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Wed, Jun 20, 2007 at 11:25:48AM -0700, Ravikiran G Thirumalai wrote: > On Wed, Jun 20, 2007 at 09:36:30AM -0400, Len Brown wrote: > > On Wednesday 20 June 2007 04:49, Andreas Herrmann wrote: > > > On Tue, Jun 19, 2007 at 11:38:02PM -0400, Len Brown wrote: > > > > On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: > > > > I fear, however, that this patch defeats the purpose of > > b0bd35e622ffbda2c01dc67a0381c6a18817a29a -- which was to make selecting > > NUMA more user-friendly. So it might make more sense to simply revert that > > patch entirely. > > > > The underlying problem is that Kconfig doesn't support using select > > on targets which themselves have dependencies. > > > > Signed-off-by: Len Brown <[EMAIL PROTECTED]> > > > > > > diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig > > index 5ce9443..e9d7767 100644 > > --- a/arch/x86_64/Kconfig > > +++ b/arch/x86_64/Kconfig > > @@ -364,9 +364,9 @@ config NODES_SHIFT > > config X86_64_ACPI_NUMA > > bool "ACPI NUMA detection" > > depends on NUMA > > - select ACPI > > + depends on ACPI > > select PCI > > - select ACPI_NUMA > > + depends on ACPI_NUMA > > default y > > help > > Enable ACPI SRAT based node topology detection. > > - > > arch/x86_64/Kconfig:706:error: found recursive dependency: PCI -> ACPI -> > X86_64_ACPI_NUMA -> PCI > -> USB_ARCH_HAS_OHCI -> USB_ARCH_HAS_HCD -> MOUSE_APPLETOUCH -> USB -> > USB_SISUSBVGAmake[1]: *** [menuconfig] Error 1 > > I guess we have to change PCI to 'depends on' as well. > Else, select PM? > > I am OK with either approach. > > Thanks, > Kiran > > Paper over 'select' inadequacies. > > Signed-off-by: Ravikiran Thirumalai <[EMAIL PROTECTED]> > > Index: linux-2.6.22-rc5/arch/x86_64/Kconfig > === > --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 16:02:19.571323415 > -0700 > +++ linux-2.6.22-rc5/arch/x86_64/Kconfig 2007-06-20 11:34:29.845354250 > -0700 > @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA > depends on NUMA > select ACPI > select PCI > + select PM > select ACPI_NUMA > default y > help Yep, this one-liner solves all acpi related compile errors/warnings that I've reported. Additional it resolves anoter problem that results from dependencies between CONFIG_PNP and CONFIG_ACPI. One problem arises: If PM is deselected, the PNP menu is empty on x86_64. So I suggest to add the attached patch to hide the PNP-menu if no PM (and thus ACPI) is selected. Regards, Andreas -- Make CONFIG_PNP a menuconfig to hide the submenu if neither ISA nor ACPI is selected. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> diff --git a/drivers/pnp/Kconfig b/drivers/pnp/Kconfig index 1959cef..2291e7d 100644 --- a/drivers/pnp/Kconfig +++ b/drivers/pnp/Kconfig @@ -2,11 +2,9 @@ # Plug and Play configuration # -menu "Plug and Play support" - depends on HAS_IOMEM - -config PNP +menuconfig PNP bool "Plug and Play support" + depends on HAS_IOMEM depends on ISA || ACPI ---help--- Plug and Play (PnP) is a standard for peripherals which allows those @@ -22,15 +20,15 @@ config PNP If unsure, say Y. +if PNP + config PNP_DEBUG bool "PnP Debug Messages" - depends on PNP help Say Y if you want the Plug and Play Layer to print debug messages. This is useful if you are developing a PnP driver or troubleshooting. comment "Protocols" - depends on PNP source "drivers/pnp/isapnp/Kconfig" @@ -38,5 +36,4 @@ source "drivers/pnp/pnpbios/Kconfig" source "drivers/pnp/pnpacpi/Kconfig" -endmenu - +endif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend on PCMCIA
On Wed, Jun 20, 2007 at 01:44:35PM -0700, Randy Dunlap wrote: > On Wed, 20 Jun 2007 00:52:03 +0200 Andreas Herrmann wrote: > > > Fix several build errors with PCMCIA=m && NET_PCMCIA=y: > > > >LD .tmp_vmlinux1 > >drivers/built-in.o: In function `nmclan_release': > >nmclan_cs.c:(.text+0x14026c): undefined reference to > > `pcmcia_disable_device' > >... > >drivers/built-in.o: In function `exit_xirc2ps_cs': > >xirc2ps_cs.c:(.exit.text+0x1055): undefined reference to > > `pcmcia_unregister_driver' > >make: *** [.tmp_vmlinux1] Error 1 > > This is interesting. This is a result of the menuconfig changes, > which made NET_PCMCIA a boolean, and then some tristates depend > on NET_PCMCIA and the boolean -> tristate dependencies aren't > specific enough. > > Your fix is one way to do it. I'd prefer to make > NET_PCMCIA a tristate instead, then let its value trickle down > to the subordinate config symbols. > > This probably means that some of the other menuconfig changes > need to be audited for this "feature." > > > Here is my preferred patch. > ~~ > > From: Randy Dunlap <[EMAIL PROTECTED]> > > Make NET_PCMCIA a tristate symbol so that net/pcmcia drivers > are constrained to M when needed. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> > --- > drivers/net/pcmcia/Kconfig | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > --- linux-2.6.22-rc5.orig/drivers/net/pcmcia/Kconfig > +++ linux-2.6.22-rc5/drivers/net/pcmcia/Kconfig > @@ -3,14 +3,14 @@ > # > > menuconfig NET_PCMCIA > - bool "PCMCIA network device support" > + tristate "PCMCIA network device support" > depends on PCMCIA Yes this solves the problem. ... and is the preferred variant. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend on PCMCIA
On Wed, Jun 20, 2007 at 01:44:35PM -0700, Randy Dunlap wrote: On Wed, 20 Jun 2007 00:52:03 +0200 Andreas Herrmann wrote: Fix several build errors with PCMCIA=m NET_PCMCIA=y: LD .tmp_vmlinux1 drivers/built-in.o: In function `nmclan_release': nmclan_cs.c:(.text+0x14026c): undefined reference to `pcmcia_disable_device' ... drivers/built-in.o: In function `exit_xirc2ps_cs': xirc2ps_cs.c:(.exit.text+0x1055): undefined reference to `pcmcia_unregister_driver' make: *** [.tmp_vmlinux1] Error 1 This is interesting. This is a result of the menuconfig changes, which made NET_PCMCIA a boolean, and then some tristates depend on NET_PCMCIA and the boolean - tristate dependencies aren't specific enough. Your fix is one way to do it. I'd prefer to make NET_PCMCIA a tristate instead, then let its value trickle down to the subordinate config symbols. This probably means that some of the other menuconfig changes need to be audited for this feature. Here is my preferred patch. ~~ From: Randy Dunlap [EMAIL PROTECTED] Make NET_PCMCIA a tristate symbol so that net/pcmcia drivers are constrained to M when needed. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- drivers/net/pcmcia/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-2.6.22-rc5.orig/drivers/net/pcmcia/Kconfig +++ linux-2.6.22-rc5/drivers/net/pcmcia/Kconfig @@ -3,14 +3,14 @@ # menuconfig NET_PCMCIA - bool PCMCIA network device support + tristate PCMCIA network device support depends on PCMCIA Yes this solves the problem. ... and is the preferred variant. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Wed, Jun 20, 2007 at 11:25:48AM -0700, Ravikiran G Thirumalai wrote: On Wed, Jun 20, 2007 at 09:36:30AM -0400, Len Brown wrote: On Wednesday 20 June 2007 04:49, Andreas Herrmann wrote: On Tue, Jun 19, 2007 at 11:38:02PM -0400, Len Brown wrote: On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: I fear, however, that this patch defeats the purpose of b0bd35e622ffbda2c01dc67a0381c6a18817a29a -- which was to make selecting NUMA more user-friendly. So it might make more sense to simply revert that patch entirely. The underlying problem is that Kconfig doesn't support using select on targets which themselves have dependencies. Signed-off-by: Len Brown [EMAIL PROTECTED] diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index 5ce9443..e9d7767 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -364,9 +364,9 @@ config NODES_SHIFT config X86_64_ACPI_NUMA bool ACPI NUMA detection depends on NUMA - select ACPI + depends on ACPI select PCI - select ACPI_NUMA + depends on ACPI_NUMA default y help Enable ACPI SRAT based node topology detection. - arch/x86_64/Kconfig:706:error: found recursive dependency: PCI - ACPI - X86_64_ACPI_NUMA - PCI - USB_ARCH_HAS_OHCI - USB_ARCH_HAS_HCD - MOUSE_APPLETOUCH - USB - USB_SISUSBVGAmake[1]: *** [menuconfig] Error 1 I guess we have to change PCI to 'depends on' as well. Else, select PM? I am OK with either approach. Thanks, Kiran Paper over 'select' inadequacies. Signed-off-by: Ravikiran Thirumalai [EMAIL PROTECTED] Index: linux-2.6.22-rc5/arch/x86_64/Kconfig === --- linux-2.6.22-rc5.orig/arch/x86_64/Kconfig 2007-06-18 16:02:19.571323415 -0700 +++ linux-2.6.22-rc5/arch/x86_64/Kconfig 2007-06-20 11:34:29.845354250 -0700 @@ -366,6 +366,7 @@ config X86_64_ACPI_NUMA depends on NUMA select ACPI select PCI + select PM select ACPI_NUMA default y help Yep, this one-liner solves all acpi related compile errors/warnings that I've reported. Additional it resolves anoter problem that results from dependencies between CONFIG_PNP and CONFIG_ACPI. One problem arises: If PM is deselected, the PNP menu is empty on x86_64. So I suggest to add the attached patch to hide the PNP-menu if no PM (and thus ACPI) is selected. Regards, Andreas -- Make CONFIG_PNP a menuconfig to hide the submenu if neither ISA nor ACPI is selected. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] diff --git a/drivers/pnp/Kconfig b/drivers/pnp/Kconfig index 1959cef..2291e7d 100644 --- a/drivers/pnp/Kconfig +++ b/drivers/pnp/Kconfig @@ -2,11 +2,9 @@ # Plug and Play configuration # -menu Plug and Play support - depends on HAS_IOMEM - -config PNP +menuconfig PNP bool Plug and Play support + depends on HAS_IOMEM depends on ISA || ACPI ---help--- Plug and Play (PnP) is a standard for peripherals which allows those @@ -22,15 +20,15 @@ config PNP If unsure, say Y. +if PNP + config PNP_DEBUG bool PnP Debug Messages - depends on PNP help Say Y if you want the Plug and Play Layer to print debug messages. This is useful if you are developing a PnP driver or troubleshooting. comment Protocols - depends on PNP source drivers/pnp/isapnp/Kconfig @@ -38,5 +36,4 @@ source drivers/pnp/pnpbios/Kconfig source drivers/pnp/pnpacpi/Kconfig -endmenu - +endif - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Tue, Jun 19, 2007 at 08:51:58PM -0700, Randy Dunlap wrote: > On Tue, 19 Jun 2007 20:49:34 -0700 Randy Dunlap wrote: > > > On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote: > > > > > On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: > > > > Avoid compile warning if !ACPI_BLACKLIST_YEAR > > > > > > > > CC drivers/acpi/blacklist.o > > > > drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" > > > > is not defined > > > > > > How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR > > > not defined? > > > Can you send it to me? > > > > 'make randconfig' does that kind of thing. It doesn't enforce/follow > > "select" clauses. > > I should have also said: randconfig is good for detecting some > missing conditions/configs or missing header files, but if you find one > that is just plain Invalid (like some of these), just say so > and do whatever you want with the patch (IMHO of course). I think of randconfig as "make config with random answers to all questions" (Or did I miss something?) This means that randconfig does not give totally random configurations. The same restrictions apply for config, randconfig and menuconfig. If not we might consider fixing scripts/kconfig/conf.c and friends. So in general a "randconfig" configurations can be generated by a user as well. He just has to give the same answers during "make config" as randconfig did. I started this randconfig thing yesterday and up to now I have looked at 16 (out of >66) configs which lead to kernel build errors with the current git tree. Of course I have seen duplicates of the problems reported. But there were just 3 (all equal) bogus configurations. There randconfig did not provide a proper file name for CONFIG_ACPI_CUSTOM_DSDT_FILE. This is the only case for which I would use the term "user error" or "bogus randconfig". IMHO if certain configurations are invalid we should use kconfig-language to prevent them. Ah and wrt to the above compile warning. Normally I would have ignored it - but I looked at acpi code and its Kconfig anyway. And It's easy to avoid such a warning to keep the terminal clear for more interesting compile messages ;-) Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/12] acpi: fix another compile warning
On Tue, Jun 19, 2007 at 11:38:02PM -0400, Len Brown wrote: > On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: > > Avoid compile warning if !ACPI_BLACKLIST_YEAR > > > > CC drivers/acpi/blacklist.o > > drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is > > not defined > > How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not > defined? Initially I used randconfig. But you can easily create it using "make menuconfig", too. Just do "make mrproper && make menuconfig" and now deselect CONFIG_PM. On x86_64 ACPI keeps enabled by default. Now additionally activate an assorted choice of laptop misc devices, like MSI_LAPTOP, THINKPAD_ACPI etc, and you get: ... drivers/misc/sony-laptop.c:1458: undefined reference to `ec_read' drivers/built-in.o: In function `acpi_ec_read': drivers/misc/thinkpad_acpi.c:247: undefined reference to `ec_read' drivers/built-in.o: In function `acpi_ec_write': drivers/misc/thinkpad_acpi.c:260: undefined reference to `ec_write' drivers/built-in.o: In function `led_write': drivers/misc/thinkpad_acpi.c:2209: undefined reference to `ec_write' ... drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is not defi ned ... drivers/acpi/bus.c: In function 'acpi_bus_get_power': drivers/acpi/bus.c:162: warning: implicit declaration of function 'acpi_power_get_inferred_state' ... In short, it is possible for a user to create such a configuration. The current kconfig for acpi and those misc devices does not prevent it. > Can you send it to me? > Attached is a configuration that I've just created with menuconfig and not randconfig. Regards, Andreas # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc5 # Wed Jun 20 10:17:48 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUM
Re: [PATCH 7/12] acpi: fix another compile warning
On Tue, Jun 19, 2007 at 11:38:02PM -0400, Len Brown wrote: On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: Avoid compile warning if !ACPI_BLACKLIST_YEAR CC drivers/acpi/blacklist.o drivers/acpi/blacklist.c:76:5: warning: CONFIG_ACPI_BLACKLIST_YEAR is not defined How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not defined? Initially I used randconfig. But you can easily create it using make menuconfig, too. Just do make mrproper make menuconfig and now deselect CONFIG_PM. On x86_64 ACPI keeps enabled by default. Now additionally activate an assorted choice of laptop misc devices, like MSI_LAPTOP, THINKPAD_ACPI etc, and you get: ... drivers/misc/sony-laptop.c:1458: undefined reference to `ec_read' drivers/built-in.o: In function `acpi_ec_read': drivers/misc/thinkpad_acpi.c:247: undefined reference to `ec_read' drivers/built-in.o: In function `acpi_ec_write': drivers/misc/thinkpad_acpi.c:260: undefined reference to `ec_write' drivers/built-in.o: In function `led_write': drivers/misc/thinkpad_acpi.c:2209: undefined reference to `ec_write' ... drivers/acpi/blacklist.c:76:5: warning: CONFIG_ACPI_BLACKLIST_YEAR is not defi ned ... drivers/acpi/bus.c: In function 'acpi_bus_get_power': drivers/acpi/bus.c:162: warning: implicit declaration of function 'acpi_power_get_inferred_state' ... In short, it is possible for a user to create such a configuration. The current kconfig for acpi and those misc devices does not prevent it. Can you send it to me? Attached is a configuration that I've just created with menuconfig and not randconfig. Regards, Andreas # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc5 # Wed Jun 20 10:17:48 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set
Re: [PATCH 7/12] acpi: fix another compile warning
On Tue, Jun 19, 2007 at 08:51:58PM -0700, Randy Dunlap wrote: On Tue, 19 Jun 2007 20:49:34 -0700 Randy Dunlap wrote: On Tue, 19 Jun 2007 23:38:02 -0400 Len Brown wrote: On Tuesday 19 June 2007 18:50, Andreas Herrmann wrote: Avoid compile warning if !ACPI_BLACKLIST_YEAR CC drivers/acpi/blacklist.o drivers/acpi/blacklist.c:76:5: warning: CONFIG_ACPI_BLACKLIST_YEAR is not defined How were you able to produce a .config with CONFIG_ACPI_BLACKLIST_YEAR not defined? Can you send it to me? 'make randconfig' does that kind of thing. It doesn't enforce/follow select clauses. I should have also said: randconfig is good for detecting some missing conditions/configs or missing header files, but if you find one that is just plain Invalid (like some of these), just say so and do whatever you want with the patch (IMHO of course). I think of randconfig as make config with random answers to all questions (Or did I miss something?) This means that randconfig does not give totally random configurations. The same restrictions apply for config, randconfig and menuconfig. If not we might consider fixing scripts/kconfig/conf.c and friends. So in general a randconfig configurations can be generated by a user as well. He just has to give the same answers during make config as randconfig did. I started this randconfig thing yesterday and up to now I have looked at 16 (out of 66) configs which lead to kernel build errors with the current git tree. Of course I have seen duplicates of the problems reported. But there were just 3 (all equal) bogus configurations. There randconfig did not provide a proper file name for CONFIG_ACPI_CUSTOM_DSDT_FILE. This is the only case for which I would use the term user error or bogus randconfig. IMHO if certain configurations are invalid we should use kconfig-language to prevent them. Ah and wrt to the above compile warning. Normally I would have ignored it - but I looked at acpi code and its Kconfig anyway. And It's easy to avoid such a warning to keep the terminal clear for more interesting compile messages ;-) Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/12] sound: fix compile error (wrong declaration of devinitdata)
Fix compile error:
CC sound/pci/ice1712/prodigy192.o
sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section
type conflict
... but __initdata cannot be "const".
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
sound/pci/ice1712/prodigy192.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/pci/ice1712/prodigy192.c b/sound/pci/ice1712/prodigy192.c
index f03c02c..4bae730 100644
--- a/sound/pci/ice1712/prodigy192.c
+++ b/sound/pci/ice1712/prodigy192.c
@@ -705,7 +705,7 @@ static int ak4114_input_sw_put(struct snd_kcontrol
*kcontrol,
}
-static const struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
+static struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = "MIODIO IEC958 Capture Input",
--
1.5.0.7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] SLOB: fix build error if SLOB && !NUMA
Fix build error: LD .tmp_vmlinux1 arch/x86_64/kernel/built-in.o: In function `__cpu_up': : undefined reference to `kmalloc_node' kernel/built-in.o: In function `build_sched_domains': sched.c:(.text+0x41e7): undefined reference to `kmalloc_node' sched.c:(.text+0x42b5): undefined reference to `kmalloc_node' kernel/built-in.o: In function `timer_cpu_notify': timer.c:(.init.text+0x1163): undefined reference to `kmalloc_node' mm/built-in.o: In function `mempool_create_node': : undefined reference to `kmalloc_node' mm/built-in.o:: more undefined references to `kmalloc_node' follow ... hmm, SLOB currently does not provide kmalloc_node() and friends. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- init/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index a9e99f8..d4a68f6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -576,7 +576,7 @@ config SLUB and has enhanced diagnostics. config SLOB - depends on EMBEDDED && !SPARSEMEM + depends on EMBEDDED && !SPARSEMEM && !NUMA bool "SLOB (Simple Allocator)" help SLOB replaces the SLAB allocator with a drastically simpler -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/12] acpi: fix compile warnings
Fix compile warnings:
drivers/acpi/bus.c: In function 'acpi_bus_get_power':
drivers/acpi/bus.c:162: warning: implicit declaration of function
'acpi_power_get_inferred_state'
drivers/acpi/bus.c: In function 'acpi_bus_set_power':
drivers/acpi/bus.c:232: warning: implicit declaration of function
'acpi_power_transition'
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index b4a9ea5..e01dca1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -43,6 +43,8 @@ ACPI_MODULE_NAME("bus");
#ifdef CONFIG_X86
extern void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger);
#endif
+extern int acpi_power_get_inferred_state(struct acpi_device *);
+extern int acpi_power_transition(struct acpi_device *, int);
struct acpi_device *acpi_root;
struct proc_dir_entry *acpi_root_dir;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] acpi: select ACPI_EC for SONY_LAPTOP
Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0d6f369..463fa41 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -119,6 +119,7 @@ config MSI_LAPTOP config SONY_LAPTOP tristate "Sony Laptop Extras" depends on X86 && ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE ---help--- This mini-driver drives the SNC and SPIC devices present in the ACPI -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/12] fix compile error (missing include)
Fix compile error:
In file included from drivers/infiniband/core/addr.c:32:
include/linux/inetdevice.h:15: error: '__NET_IPV4_CONF_MAX' undeclared here
(not in a function)
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
include/linux/inetdevice.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index ae04901..d83fee2 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
struct ipv4_devconf
{
--
1.5.0.7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend on PCMCIA
Fix several build errors with PCMCIA=m && NET_PCMCIA=y: LD .tmp_vmlinux1 drivers/built-in.o: In function `nmclan_release': nmclan_cs.c:(.text+0x14026c): undefined reference to `pcmcia_disable_device' ... drivers/built-in.o: In function `exit_xirc2ps_cs': xirc2ps_cs.c:(.exit.text+0x1055): undefined reference to `pcmcia_unregister_driver' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/net/pcmcia/Kconfig | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig index 5d658bc..9545440 100644 --- a/drivers/net/pcmcia/Kconfig +++ b/drivers/net/pcmcia/Kconfig @@ -23,6 +23,7 @@ if NET_PCMCIA config PCMCIA_3C589 tristate "3Com 3c589 PCMCIA support" + depends on PCMCIA help Say Y here if you intend to attach a 3Com 3c589 or compatible PCMCIA (PC-card) Ethernet card to your computer. @@ -32,6 +33,7 @@ config PCMCIA_3C589 config PCMCIA_3C574 tristate "3Com 3c574 PCMCIA support" + depends on PCMCIA help Say Y here if you intend to attach a 3Com 3c574 or compatible PCMCIA (PC-card) Fast Ethernet card to your computer. @@ -41,6 +43,7 @@ config PCMCIA_3C574 config PCMCIA_FMVJ18X tristate "Fujitsu FMV-J18x PCMCIA support" + depends on PCMCIA select CRC32 help Say Y here if you intend to attach a Fujitsu FMV-J18x or compatible @@ -51,6 +54,7 @@ config PCMCIA_FMVJ18X config PCMCIA_PCNET tristate "NE2000 compatible PCMCIA support" + depends on PCMCIA select CRC32 help Say Y here if you intend to attach an NE2000 compatible PCMCIA @@ -61,6 +65,7 @@ config PCMCIA_PCNET config PCMCIA_NMCLAN tristate "New Media PCMCIA support" + depends on PCMCIA help Say Y here if you intend to attach a New Media Ethernet or LiveWire PCMCIA (PC-card) Ethernet card to your computer. @@ -70,6 +75,7 @@ config PCMCIA_NMCLAN config PCMCIA_SMC91C92 tristate "SMC 91Cxx PCMCIA support" + depends on PCMCIA select CRC32 select MII help @@ -81,6 +87,7 @@ config PCMCIA_SMC91C92 config PCMCIA_XIRC2PS tristate "Xircom 16-bit PCMCIA support" + depends on PCMCIA help Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card) Ethernet or Fast Ethernet card to your computer. @@ -90,6 +97,7 @@ config PCMCIA_XIRC2PS config PCMCIA_AXNET tristate "Asix AX88190 PCMCIA support" + depends on PCMCIA ---help--- Say Y here if you intend to attach an Asix AX88190-based PCMCIA (PC-card) Fast Ethernet card to your computer. These cards are @@ -101,7 +109,7 @@ config PCMCIA_AXNET config ARCNET_COM20020_CS tristate "COM20020 ARCnet PCMCIA support" - depends on ARCNET_COM20020 + depends on ARCNET_COM20020 && PCMCIA help Say Y here if you intend to attach this type of ARCnet PCMCIA card to your computer. @@ -111,7 +119,7 @@ config ARCNET_COM20020_CS config PCMCIA_IBMTR tristate "IBM PCMCIA tokenring adapter support" - depends on IBMTR!=y && TR && !64BIT + depends on IBMTR!=y && TR && !64BIT && PCMCIA help Say Y here if you intend to attach this type of Token Ring PCMCIA card to your computer. You then also need to say Y to "Token Ring -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/12] acpi: fix another compile warning
Avoid compile warning if !ACPI_BLACKLIST_YEAR
CC drivers/acpi/blacklist.o
drivers/acpi/blacklist.c:76:5: warning: "CONFIG_ACPI_BLACKLIST_YEAR" is not
defined
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/acpi/blacklist.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 3ec110c..ac96c47 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -73,7 +73,7 @@ static struct acpi_blacklist_item acpi_blacklist[] __initdata
= {
{""}
};
-#ifCONFIG_ACPI_BLACKLIST_YEAR
+#ifdefined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
static int __init blacklist_by_year(void)
{
--
1.5.0.7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/12] acpi: fix compile error with ACPI && !ACPI_SYSTEM
Fix build error if ACPI && !ACPI_SYSTEM as
bus.c depended on event.c
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/acpi/bus.c |2 +-
drivers/acpi/event.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index e5084ec..b4a9ea5 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -281,7 +281,7 @@ static DEFINE_SPINLOCK(acpi_bus_event_lock);
LIST_HEAD(acpi_bus_event_list);
DECLARE_WAIT_QUEUE_HEAD(acpi_bus_event_queue);
-extern int event_is_open;
+int event_is_open = 0;
int acpi_bus_generate_event(struct acpi_device *device, u8 type, int data)
{
diff --git a/drivers/acpi/event.c b/drivers/acpi/event.c
index 3b23562..15886c1 100644
--- a/drivers/acpi/event.c
+++ b/drivers/acpi/event.c
@@ -17,7 +17,7 @@ ACPI_MODULE_NAME("event");
/* Global vars for handling event proc entry */
static DEFINE_SPINLOCK(acpi_system_event_lock);
-int event_is_open = 0;
+extern int event_is_open;
extern struct list_head acpi_bus_event_list;
extern wait_queue_head_t acpi_bus_event_queue;
--
1.5.0.7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/12] acpi: fix compile error with ACPI && !ACPI_POWER
Fix compile error with ACPI && !ACPI_POWER as bus.c depends on power.c Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig |4 drivers/acpi/Makefile |2 +- 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 139f41f..9d6baab 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -288,10 +288,6 @@ config ACPI_EC the battery and thermal drivers. If you are compiling for a mobile system, say Y. -config ACPI_POWER - bool - default y - config ACPI_SYSTEM bool default y diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index d4336f1..9485cc3 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -48,7 +48,7 @@ obj-$(CONFIG_ACPI_DOCK) += dock.o obj-$(CONFIG_ACPI_BAY) += bay.o obj-$(CONFIG_ACPI_VIDEO) += video.o obj-y += pci_root.o pci_link.o pci_irq.o pci_bind.o -obj-$(CONFIG_ACPI_POWER) += power.o +obj-y += power.o obj-$(CONFIG_ACPI_PROCESSOR) += processor.o obj-$(CONFIG_ACPI_CONTAINER) += container.o obj-$(CONFIG_ACPI_THERMAL) += thermal.o -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/12] acpi: select ACPI_EC for MSI_LAPTOP
Fix kernel build problem as MSI_LAPTOP depends on ACPI_EC. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 72774c9..0d6f369 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -99,8 +99,8 @@ config ASUS_LAPTOP config MSI_LAPTOP tristate "MSI Laptop Extras" -depends on X86 -depends on ACPI_EC +depends on X86 && ACPI +select ACPI_EC depends on BACKLIGHT_CLASS_DEVICE ---help--- This is a driver for laptops built by MSI (MICRO-STAR -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/12] acpi: select ACPI_EC for THINKPAD_ACPI
Fix kernel build problem: thinkpad_acpi.c:(.text+0x7486a): undefined reference to `ec_write' (as THINKPAD_ACPI depends on ACPI_EC) Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2f2fbff..72774c9 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -139,6 +139,7 @@ config SONYPI_COMPAT config THINKPAD_ACPI tristate "ThinkPad ACPI Laptop Extras" depends on X86 && ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE select HWMON ---help--- -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/12] m68k: fix annoying Kconfig warning
Fix Kconfig build warning: scripts/kconfig/mconf arch/x86_64/Kconfig drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- arch/m68k/Kconfig |3 --- drivers/input/keyboard/Kconfig |4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 85cdd23..a86e2e9 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -418,9 +418,6 @@ config STRAM_PROC help Say Y here to report ST-RAM usage statistics in /proc/stram. -config ATARI_KBD_CORE - bool - config HEARTBEAT bool "Use power LED as a heartbeat" if AMIGA || APOLLO || ATARI || MAC ||Q40 default y if !AMIGA && !APOLLO && !ATARI && !MAC && !Q40 && HP300 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index bd707b8..e89394c 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -164,6 +164,10 @@ config KEYBOARD_AMIGA To compile this driver as a module, choose M here: the module will be called amikbd. +config ATARI_KBD_CORE + depends on ATARI + bool + config KEYBOARD_ATARI tristate "Atari keyboard" depends on ATARI -- 1.5.0.7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/12] several fixes from randconfig compiles
This is a series of minor fixes for problems observed while doing some randconfig fun on x86_64. Some problems might have been reported on LKML before. But AFAIK they are not fixed in current git. Thus I report them again - including possible fixes. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company & Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/12] several fixes from randconfig compiles
This is a series of minor fixes for problems observed while doing some randconfig fun on x86_64. Some problems might have been reported on LKML before. But AFAIK they are not fixed in current git. Thus I report them again - including possible fixes. Regards, Andreas -- Operating | AMD Saxony Limited Liability Company Co. KG, System | Wilschdorfer Landstr. 101, 01109 Dresden, Germany Research | Register Court Dresden: HRA 4896, General Partner authorized Center | to represent: AMD Saxony LLC (Wilmington, Delaware, US) (OSRC) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/12] m68k: fix annoying Kconfig warning
Fix Kconfig build warning: scripts/kconfig/mconf arch/x86_64/Kconfig drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- arch/m68k/Kconfig |3 --- drivers/input/keyboard/Kconfig |4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 85cdd23..a86e2e9 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -418,9 +418,6 @@ config STRAM_PROC help Say Y here to report ST-RAM usage statistics in /proc/stram. -config ATARI_KBD_CORE - bool - config HEARTBEAT bool Use power LED as a heartbeat if AMIGA || APOLLO || ATARI || MAC ||Q40 default y if !AMIGA !APOLLO !ATARI !MAC !Q40 HP300 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig index bd707b8..e89394c 100644 --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -164,6 +164,10 @@ config KEYBOARD_AMIGA To compile this driver as a module, choose M here: the module will be called amikbd. +config ATARI_KBD_CORE + depends on ATARI + bool + config KEYBOARD_ATARI tristate Atari keyboard depends on ATARI -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/12] acpi: select ACPI_EC for THINKPAD_ACPI
Fix kernel build problem: thinkpad_acpi.c:(.text+0x7486a): undefined reference to `ec_write' (as THINKPAD_ACPI depends on ACPI_EC) Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 2f2fbff..72774c9 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -139,6 +139,7 @@ config SONYPI_COMPAT config THINKPAD_ACPI tristate ThinkPad ACPI Laptop Extras depends on X86 ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE select HWMON ---help--- -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/12] acpi: select ACPI_EC for MSI_LAPTOP
Fix kernel build problem as MSI_LAPTOP depends on ACPI_EC. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/misc/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 72774c9..0d6f369 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -99,8 +99,8 @@ config ASUS_LAPTOP config MSI_LAPTOP tristate MSI Laptop Extras -depends on X86 -depends on ACPI_EC +depends on X86 ACPI +select ACPI_EC depends on BACKLIGHT_CLASS_DEVICE ---help--- This is a driver for laptops built by MSI (MICRO-STAR -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/12] acpi: fix compile error with ACPI !ACPI_POWER
Fix compile error with ACPI !ACPI_POWER as bus.c depends on power.c Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/acpi/Kconfig |4 drivers/acpi/Makefile |2 +- 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 139f41f..9d6baab 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -288,10 +288,6 @@ config ACPI_EC the battery and thermal drivers. If you are compiling for a mobile system, say Y. -config ACPI_POWER - bool - default y - config ACPI_SYSTEM bool default y diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index d4336f1..9485cc3 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -48,7 +48,7 @@ obj-$(CONFIG_ACPI_DOCK) += dock.o obj-$(CONFIG_ACPI_BAY) += bay.o obj-$(CONFIG_ACPI_VIDEO) += video.o obj-y += pci_root.o pci_link.o pci_irq.o pci_bind.o -obj-$(CONFIG_ACPI_POWER) += power.o +obj-y += power.o obj-$(CONFIG_ACPI_PROCESSOR) += processor.o obj-$(CONFIG_ACPI_CONTAINER) += container.o obj-$(CONFIG_ACPI_THERMAL) += thermal.o -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/12] acpi: fix another compile warning
Avoid compile warning if !ACPI_BLACKLIST_YEAR
CC drivers/acpi/blacklist.o
drivers/acpi/blacklist.c:76:5: warning: CONFIG_ACPI_BLACKLIST_YEAR is not
defined
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/acpi/blacklist.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c
index 3ec110c..ac96c47 100644
--- a/drivers/acpi/blacklist.c
+++ b/drivers/acpi/blacklist.c
@@ -73,7 +73,7 @@ static struct acpi_blacklist_item acpi_blacklist[] __initdata
= {
{}
};
-#ifCONFIG_ACPI_BLACKLIST_YEAR
+#ifdefined(CONFIG_ACPI_BLACKLIST_YEAR) CONFIG_ACPI_BLACKLIST_YEAR
static int __init blacklist_by_year(void)
{
--
1.5.0.7
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/12] acpi: fix compile error with ACPI !ACPI_SYSTEM
Fix build error if ACPI !ACPI_SYSTEM as
bus.c depended on event.c
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/acpi/bus.c |2 +-
drivers/acpi/event.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index e5084ec..b4a9ea5 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -281,7 +281,7 @@ static DEFINE_SPINLOCK(acpi_bus_event_lock);
LIST_HEAD(acpi_bus_event_list);
DECLARE_WAIT_QUEUE_HEAD(acpi_bus_event_queue);
-extern int event_is_open;
+int event_is_open = 0;
int acpi_bus_generate_event(struct acpi_device *device, u8 type, int data)
{
diff --git a/drivers/acpi/event.c b/drivers/acpi/event.c
index 3b23562..15886c1 100644
--- a/drivers/acpi/event.c
+++ b/drivers/acpi/event.c
@@ -17,7 +17,7 @@ ACPI_MODULE_NAME(event);
/* Global vars for handling event proc entry */
static DEFINE_SPINLOCK(acpi_system_event_lock);
-int event_is_open = 0;
+extern int event_is_open;
extern struct list_head acpi_bus_event_list;
extern wait_queue_head_t acpi_bus_event_queue;
--
1.5.0.7
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/12] fix compile error (missing include)
Fix compile error:
In file included from drivers/infiniband/core/addr.c:32:
include/linux/inetdevice.h:15: error: '__NET_IPV4_CONF_MAX' undeclared here
(not in a function)
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
include/linux/inetdevice.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index ae04901..d83fee2 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -8,6 +8,7 @@
#include linux/netdevice.h
#include linux/rcupdate.h
#include linux/timer.h
+#include linux/sysctl.h
struct ipv4_devconf
{
--
1.5.0.7
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/12] pcmcia/net_pcmcia: all net_pcmcia modules depend on PCMCIA
Fix several build errors with PCMCIA=m NET_PCMCIA=y: LD .tmp_vmlinux1 drivers/built-in.o: In function `nmclan_release': nmclan_cs.c:(.text+0x14026c): undefined reference to `pcmcia_disable_device' ... drivers/built-in.o: In function `exit_xirc2ps_cs': xirc2ps_cs.c:(.exit.text+0x1055): undefined reference to `pcmcia_unregister_driver' make: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/net/pcmcia/Kconfig | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/pcmcia/Kconfig b/drivers/net/pcmcia/Kconfig index 5d658bc..9545440 100644 --- a/drivers/net/pcmcia/Kconfig +++ b/drivers/net/pcmcia/Kconfig @@ -23,6 +23,7 @@ if NET_PCMCIA config PCMCIA_3C589 tristate 3Com 3c589 PCMCIA support + depends on PCMCIA help Say Y here if you intend to attach a 3Com 3c589 or compatible PCMCIA (PC-card) Ethernet card to your computer. @@ -32,6 +33,7 @@ config PCMCIA_3C589 config PCMCIA_3C574 tristate 3Com 3c574 PCMCIA support + depends on PCMCIA help Say Y here if you intend to attach a 3Com 3c574 or compatible PCMCIA (PC-card) Fast Ethernet card to your computer. @@ -41,6 +43,7 @@ config PCMCIA_3C574 config PCMCIA_FMVJ18X tristate Fujitsu FMV-J18x PCMCIA support + depends on PCMCIA select CRC32 help Say Y here if you intend to attach a Fujitsu FMV-J18x or compatible @@ -51,6 +54,7 @@ config PCMCIA_FMVJ18X config PCMCIA_PCNET tristate NE2000 compatible PCMCIA support + depends on PCMCIA select CRC32 help Say Y here if you intend to attach an NE2000 compatible PCMCIA @@ -61,6 +65,7 @@ config PCMCIA_PCNET config PCMCIA_NMCLAN tristate New Media PCMCIA support + depends on PCMCIA help Say Y here if you intend to attach a New Media Ethernet or LiveWire PCMCIA (PC-card) Ethernet card to your computer. @@ -70,6 +75,7 @@ config PCMCIA_NMCLAN config PCMCIA_SMC91C92 tristate SMC 91Cxx PCMCIA support + depends on PCMCIA select CRC32 select MII help @@ -81,6 +87,7 @@ config PCMCIA_SMC91C92 config PCMCIA_XIRC2PS tristate Xircom 16-bit PCMCIA support + depends on PCMCIA help Say Y here if you intend to attach a Xircom 16-bit PCMCIA (PC-card) Ethernet or Fast Ethernet card to your computer. @@ -90,6 +97,7 @@ config PCMCIA_XIRC2PS config PCMCIA_AXNET tristate Asix AX88190 PCMCIA support + depends on PCMCIA ---help--- Say Y here if you intend to attach an Asix AX88190-based PCMCIA (PC-card) Fast Ethernet card to your computer. These cards are @@ -101,7 +109,7 @@ config PCMCIA_AXNET config ARCNET_COM20020_CS tristate COM20020 ARCnet PCMCIA support - depends on ARCNET_COM20020 + depends on ARCNET_COM20020 PCMCIA help Say Y here if you intend to attach this type of ARCnet PCMCIA card to your computer. @@ -111,7 +119,7 @@ config ARCNET_COM20020_CS config PCMCIA_IBMTR tristate IBM PCMCIA tokenring adapter support - depends on IBMTR!=y TR !64BIT + depends on IBMTR!=y TR !64BIT PCMCIA help Say Y here if you intend to attach this type of Token Ring PCMCIA card to your computer. You then also need to say Y to Token Ring -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/12] acpi: select ACPI_EC for SONY_LAPTOP
Fix kernel build problem as SONY_LAPTOP depends on ACPI_EC. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/misc/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0d6f369..463fa41 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -119,6 +119,7 @@ config MSI_LAPTOP config SONY_LAPTOP tristate Sony Laptop Extras depends on X86 ACPI + select ACPI_EC select BACKLIGHT_CLASS_DEVICE ---help--- This mini-driver drives the SNC and SPIC devices present in the ACPI -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/12] acpi: fix compile warnings
Fix compile warnings: drivers/acpi/bus.c: In function 'acpi_bus_get_power': drivers/acpi/bus.c:162: warning: implicit declaration of function 'acpi_power_get_inferred_state' drivers/acpi/bus.c: In function 'acpi_bus_set_power': drivers/acpi/bus.c:232: warning: implicit declaration of function 'acpi_power_transition' Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c index b4a9ea5..e01dca1 100644 --- a/drivers/acpi/bus.c +++ b/drivers/acpi/bus.c @@ -43,6 +43,8 @@ ACPI_MODULE_NAME(bus); #ifdef CONFIG_X86 extern void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger); #endif +extern int acpi_power_get_inferred_state(struct acpi_device *); +extern int acpi_power_transition(struct acpi_device *, int); struct acpi_device *acpi_root; struct proc_dir_entry *acpi_root_dir; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/12] SLOB: fix build error if SLOB !NUMA
Fix build error: LD .tmp_vmlinux1 arch/x86_64/kernel/built-in.o: In function `__cpu_up': : undefined reference to `kmalloc_node' kernel/built-in.o: In function `build_sched_domains': sched.c:(.text+0x41e7): undefined reference to `kmalloc_node' sched.c:(.text+0x42b5): undefined reference to `kmalloc_node' kernel/built-in.o: In function `timer_cpu_notify': timer.c:(.init.text+0x1163): undefined reference to `kmalloc_node' mm/built-in.o: In function `mempool_create_node': : undefined reference to `kmalloc_node' mm/built-in.o:: more undefined references to `kmalloc_node' follow ... hmm, SLOB currently does not provide kmalloc_node() and friends. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- init/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index a9e99f8..d4a68f6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -576,7 +576,7 @@ config SLUB and has enhanced diagnostics. config SLOB - depends on EMBEDDED !SPARSEMEM + depends on EMBEDDED !SPARSEMEM !NUMA bool SLOB (Simple Allocator) help SLOB replaces the SLAB allocator with a drastically simpler -- 1.5.0.7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/12] sound: fix compile error (wrong declaration of devinitdata)
Fix compile error:
CC sound/pci/ice1712/prodigy192.o
sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section
type conflict
... but __initdata cannot be const.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
sound/pci/ice1712/prodigy192.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/pci/ice1712/prodigy192.c b/sound/pci/ice1712/prodigy192.c
index f03c02c..4bae730 100644
--- a/sound/pci/ice1712/prodigy192.c
+++ b/sound/pci/ice1712/prodigy192.c
@@ -705,7 +705,7 @@ static int ak4114_input_sw_put(struct snd_kcontrol
*kcontrol,
}
-static const struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
+static struct snd_kcontrol_new ak4114_controls[] __devinitdata = {
{
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = MIODIO IEC958 Capture Input,
--
1.5.0.7
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: prevent auto select of mwait_idle for AMD CPUs
On Tue, Apr 10, 2007 at 08:11:18PM +0200, Andi Kleen wrote: > On Tuesday 10 April 2007 19:24:25 Andreas Herrmann wrote: > > This fix is needed for AMD family 10h CPUs. > > > > It prevents auto select of mwait_idle for AMD CPUs. > > MWAIT does not enter C-states on family 10h and more > > power saving is reached by entering C1 with > > default_idle. > > > > The patch also adds an idle=mwait command line option > > to select mwait_idle for benchmarking. > > I already did my own patch earlier. Applied for reference. > > -Andi Great. Your patch is the better solution. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: prevent auto select of mwait_idle for AMD CPUs
On Tue, Apr 10, 2007 at 08:11:18PM +0200, Andi Kleen wrote: On Tuesday 10 April 2007 19:24:25 Andreas Herrmann wrote: This fix is needed for AMD family 10h CPUs. It prevents auto select of mwait_idle for AMD CPUs. MWAIT does not enter C-states on family 10h and more power saving is reached by entering C1 with default_idle. The patch also adds an idle=mwait command line option to select mwait_idle for benchmarking. I already did my own patch earlier. Applied for reference. -Andi Great. Your patch is the better solution. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: prevent auto select of mwait_idle for AMD CPUs
Actually I have also written patches to clear the MWAIT flag for AMD CPUs. But after re-reading of specs (also Intel's specs) I preferred to keep the MWAIT flag but to introduce a MWAIT_NO_CSTATE flag. I think this is the cleaner solution. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
