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 = {
{""}
};
-#if CONFIG_ACPI_BLACKLIST_YEAR
+#if defined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
static int __init blacklist_by_year(void)
{
--
1.5.0.7
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?
thanks,
-Len
> 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 = {
> {""}
> };
>
> -#if CONFIG_ACPI_BLACKLIST_YEAR
> +#if defined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
>
> static int __init blacklist_by_year(void)
> {
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.
> thanks,
> -Len
>
> > 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 = {
> > {""}
> > };
> >
> > -#if CONFIG_ACPI_BLACKLIST_YEAR
> > +#if defined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
> >
> > static int __init blacklist_by_year(void)
> > {
> -
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
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).
> > thanks,
> > -Len
> >
> > > 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 = {
> > > {""}
> > > };
> > >
> > > -#if CONFIG_ACPI_BLACKLIST_YEAR
> > > +#if defined(CONFIG_ACPI_BLACKLIST_YEAR) && CONFIG_ACPI_BLACKLIST_YEAR
> > >
> > > static int __init blacklist_by_year(void)
> > > {
> > -
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On Tuesday 19 June 2007 23:51, 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).
If randconfig ends up with impossible-for-a-user-to-generate configs,
then it seems seriously broken. Perhaps it would make sense to run
"make oldconfig" after "make randconfig" -- or better yet, have that
built in?
-Len
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
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
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:
> > > 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.
As CONFIG_ACPI depends on CONFIG_PM, then if you are able to end up
with a config having ACPI && !PM, then the Kconfig system is broken.
The brokeness is x86_64 specific, and results from the "select ACPI" below.
Please test if this single patch fixes all your multiple ACPI related build errors.
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.
> The underlying problem is that Kconfig doesn't support using select
> on targets which themselves have dependencies.
>
> Signed-off-by: Len Brown <[email protected]>
The depends on ACPI is fine by me, but I would prefer if the
ACPI_NUMA dependency worked the other way round (APCI_NUMA default y
and depends on the relevant architecture specific symbols). That would
be more user friendly I think because all the NUMA options would
be in one place.
-Andi
> 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.
>
Andreas Herrmann wrote:
> 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.
The last time that I looked at the config code, randconfig generates
a random value for config symbols, taking "depends on" into account,
but it does not take "select" into account. Or put another way,
it does not follow "select" chains.
and IIRC, running "make oldconfig" after that still won't enforce
the "select"s. This is a long-running problem and one of the problems
with using "select" at all.
> 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
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
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
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
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/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.
>
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
> On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[email protected]> wrote:
> 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
argh. (and not just argh-at-your-email-client).
I went through some hair-tearing a few months ago working out why it is so
damn hard to make CONFIG_PM go away and then I fixed it. And now you're
proposing a change which would reinstate the obnoxious old behaviour.
Is the "bug" which you're "fixing" here caused by the randconfig
inadequacies? Because randconfig is just busted and simply should auto-run
oldconfig.
On Fri, 22 Jun 2007 20:55:30 -0700 Andrew Morton wrote:
> > On Wed, 20 Jun 2007 11:25:48 -0700 Ravikiran G Thirumalai <[email protected]> wrote:
> > 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
>
> argh. (and not just argh-at-your-email-client).
>
> I went through some hair-tearing a few months ago working out why it is so
> damn hard to make CONFIG_PM go away and then I fixed it. And now you're
> proposing a change which would reinstate the obnoxious old behaviour.
>
> Is the "bug" which you're "fixing" here caused by the randconfig
> inadequacies? Because randconfig is just busted and simply should auto-run
> oldconfig.
Running oldconfig won't fix randconfigs that have busted "select"
chains (i.e., select does not follow chains like "depends on" does).
However, lots of this bustage isn't due to randconfig at all.
It's due to Jan E.'s menuconfig changes (yes, which I supported).
It seems that Jan didn't realize that a transition of a tristate symbol
to a boolean converts y or m to y (and n to n) and all (?) of the new
menuconfig symbols that control whether a menu is displayed or not
are boolean. One simple "fix" (or workaround) is to make them
tristate. Now that seems a little odd for a symbol that just controls
whether a menu is displayed or not, so Satyam Sharma has made some
other suggestions, and of course Andreas Herrmann has produced lots
of patches to fix various issues that he has run into.
I can't tell you the final answer (I proposed the tristate fix).
I don't particularly like some of the patches that change
depends on XYZ
to
depends on XYZ && ksymbol
in many lines of kconfig entries.
Not that it answers your question, but we should have hit this
in -mm, not in mainline, but it appears that our testing was a bit
insufficient.
And of course, if someone would fix kconfig to follow "select" chains,
we should bestow an award on them. :)
(however, I don't know if Roman would merge that patch)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***