[PATCH] platform/x86: Fix recursive Kconfig dependency

[PATCH] platform/x86: Fix recursive Kconfig dependency

[Peter Huewe]

This patch removes a recursive dependency which causes a build failure
[1-3] by changing the ASUS_WMI from select ACPI_WMI to depend on
ACPI_WMI as most other _WMI config options do.

Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
---
Error Message:
drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
drivers/platform/x86/Kconfig:422:	symbol EEEPC_WMI depends on ACPI_WMI
drivers/platform/x86/Kconfig:438:	symbol ACPI_WMI is selected by ACER_WMI
drivers/platform/x86/Kconfig:18:	symbol ACER_WMI depends on LEDS_CLASS
drivers/leds/Kconfig:10:	symbol LEDS_CLASS is selected by EEEPC_WMI


References:
[1] http://kisskb.ellerman.id.au/kisskb/buildresult/3607123/
[2] http://kisskb.ellerman.id.au/kisskb/buildresult/3607218/
[3] http://kisskb.ellerman.id.au/kisskb/buildresult/3607139/

KernelVersion: linux-next-20101208

 drivers/platform/x86/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 4c7f8b9..ddf384a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -23,7 +23,7 @@ config ACER_WMI
 	depends on BACKLIGHT_CLASS_DEVICE
 	depends on SERIO_I8042
 	depends on RFKILL || RFKILL = n
-	select ACPI_WMI
+	depends on ACPI_WMI
 	---help---
 	  This is a driver for newer Acer (and Wistron) laptops. It adds
 	  wireless radio and bluetooth control, and on some laptops,
-- 
1.7.2.2

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Peter Hüwe]

Am Donnerstag 09 Dezember 2010, 00:29:30 schrieb Peter Huewe:
> This patch removes a recursive dependency which causes a build failure
> [1-3] by changing the ASUS_WMI from select ACPI_WMI to depend on
> ACPI_WMI as most other _WMI config options do.
> 
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
> ---
> Error Message:
> drivers/platform/x86/Kconfig:422:error: recursive dependency detected!
> drivers/platform/x86/Kconfig:422:	symbol EEEPC_WMI depends on ACPI_WMI
> drivers/platform/x86/Kconfig:438:	symbol ACPI_WMI is selected by ACER_WMI
> drivers/platform/x86/Kconfig:18:	symbol ACER_WMI depends on LEDS_CLASS
> drivers/leds/Kconfig:10:	symbol LEDS_CLASS is selected by EEEPC_WMI
> 
> 
> References:
> [1] http://kisskb.ellerman.id.au/kisskb/buildresult/3607123/
> [2] http://kisskb.ellerman.id.au/kisskb/buildresult/3607218/
> [3] http://kisskb.ellerman.id.au/kisskb/buildresult/3607139/
> 
> KernelVersion: linux-next-20101208
> 


Ping - Any updates yet ?

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Corentin Chary]

On Wed, Dec 15, 2010 at 9:35 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
> Am Donnerstag 09 Dezember 2010, 00:29:30 schrieb Peter Huewe:
>> This patch removes a recursive dependency which causes a build failure
>> [1-3] by changing the ASUS_WMI from select ACPI_WMI to depend on
>> ACPI_WMI as most other _WMI config options do.
>>
>> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>

Hi, another patch was posted before:

http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/match=acpi_wmi

Randy Dunlap sort of Acked it ("Ah, that's what Sedat's patch does.  Good.")
http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/971/match=acpi_wmi

Your patch seems to miss TC1100_WMI section.

-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Randy Dunlap]

On 12/15/10 12:49, Corentin Chary wrote:
> On Wed, Dec 15, 2010 at 9:35 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
>> Am Donnerstag 09 Dezember 2010, 00:29:30 schrieb Peter Huewe:
>>> This patch removes a recursive dependency which causes a build failure
>>> [1-3] by changing the ASUS_WMI from select ACPI_WMI to depend on
>>> ACPI_WMI as most other _WMI config options do.
>>>
>>> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
> 
> Hi, another patch was posted before:
> 
> http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/match=acpi_wmi
> 
> Randy Dunlap sort of Acked it ("Ah, that's what Sedat's patch does.  Good.")
> http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/971/match=acpi_wmi

For Matthew:
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>

> 
> Your patch seems to miss TC1100_WMI section.

Yes, it would be better to do both (all) of them the same way.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Peter Hüwe]

Am Mittwoch 15 Dezember 2010, 21:51:04 schrieb Randy Dunlap:
> > Hi, another patch was posted before:
> > 
> > http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/match
> > =acpi_wmi
Thanks for the information.

> > Your patch seems to miss TC1100_WMI section.
> 
> Yes, it would be better to do both (all) of them the same way.
Yeah, you're right - but as Sedat's patch is perfect (and fixes both) - so for 
Sedats's patch:
Acked-by: Peter Huewe <peterhuewe@gmx.de>

Thanks,
Peter

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Sedat Dilek]

On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
> Am Mittwoch 15 Dezember 2010, 21:51:04 schrieb Randy Dunlap:
>> > Hi, another patch was posted before:
>> >
>> > http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/match
>> > =acpi_wmi
> Thanks for the information.
>
>> > Your patch seems to miss TC1100_WMI section.
>>
>> Yes, it would be better to do both (all) of them the same way.
> Yeah, you're right - but as Sedat's patch is perfect (and fixes both) - so for
> Sedats's patch:
> Acked-by: Peter Huewe <peterhuewe@gmx.de>
>
> Thanks,
> Peter
>

[ CC John Linville ]

It's a bit disappointing to see my fix is still not in
platform-drivers-x86/linux-next [1] (even it's only fixing "warnings",
9 days past).
linux-next tree is for me a very high dynamic SCM tree, I am doing
mostly daily builds, at weekend I am testing/pulling other trees
before they go into Monday's linux-next.
As far as I have fun with "my process"... I will continue.

Yesterday, I provided a patch which broke iwlwifi in linux-next
(next-20101216) and it was applied quickly into wireless-next-2.6 GIT
master and it is in next day's linux-next. OK, this was a breakage not
fixing warnings (which can be of course ignored).

Yesterday, I had a talk with resposibles of GRML project, because they
refused to apply a 6-months-old patch from IIRC Eric Biederman(n).
Debian has it already in their linux-2.6 SCM as:
       bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch

To be honest, I can't understand why this patch is still not upstream
(even it is a "cosmetic" fix).

So what shall I do: Cry louder, ignore, resend???

Next very unamused thingie is, sometimes you do not get a feedback, if
a patch is in WTF tree applied or not, so I am replying myself to the
threads so that people are informed that stuff is closed, please go on
to next of your problems.

As a conclusion for myself, it highly depends on the submaintainer...

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=shortlog;h=refs/heads/linux-next

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Peter Hüwe]

Am Freitag 17 Dezember 2010, 12:30:15 schrieb Sedat Dilek:
> On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
> > Am Mittwoch 15 Dezember 2010, 21:51:04 schrieb Randy Dunlap:
> >> > Hi, another patch was posted before:
> >> > 
> >> > http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/ma
> >> > tch =acpi_wmi
> >> >Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > Yeah, you're right - but as Sedat's patch is perfect (and fixes both) -
> > so for Sedats's patch:
> > Acked-by: Peter Huewe <peterhuewe@gmx.de>
> > 
> > Thanks,
> > Peter
> 
> [ CC John Linville ]
> 
> It's a bit disappointing to see my fix is still not in
> platform-drivers-x86/linux-next [1] (even it's only fixing "warnings",
> 9 days past).
> linux-next tree is for me a very high dynamic SCM tree, I am doing
> mostly daily builds, at weekend I am testing/pulling other trees
> before they go into Monday's linux-next.
> As far as I have fun with "my process"... I will continue.



Added Stephen Rothwell on CC, maybe he can apply it directly to linux-next ;)

Peter

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Sedat Dilek]

On Sun, Dec 19, 2010 at 8:00 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
> Am Freitag 17 Dezember 2010, 12:30:15 schrieb Sedat Dilek:
>> On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
>> > Am Mittwoch 15 Dezember 2010, 21:51:04 schrieb Randy Dunlap:
>> >> > Hi, another patch was posted before:
>> >> >
>> >> > http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/970/ma
>> >> > tch =acpi_wmi
>> >> >Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
>> >
>> > Yeah, you're right - but as Sedat's patch is perfect (and fixes both) -
>> > so for Sedats's patch:
>> > Acked-by: Peter Huewe <peterhuewe@gmx.de>
>> >
>> > Thanks,
>> > Peter
>>
>> [ CC John Linville ]
>>
>> It's a bit disappointing to see my fix is still not in
>> platform-drivers-x86/linux-next [1] (even it's only fixing "warnings",
>> 9 days past).
>> linux-next tree is for me a very high dynamic SCM tree, I am doing
>> mostly daily builds, at weekend I am testing/pulling other trees
>> before they go into Monday's linux-next.
>> As far as I have fun with "my process"... I will continue.
>
>
>
> Added Stephen Rothwell on CC, maybe he can apply it directly to linux-next ;)
>
> Peter
>

I do not think this will happen for a "as-warning-classified" patch.
As far as I understood from a previous asking to accept a patch
through Stephen, he answered me that he is expecting that patches for
sub-trees shall be pushed by the sub-maintainer(s).
This is surely the optimal way.

There is a nice, informative interview with Stephen on topic of
linux-next [1] (working together with submaintainers etc.).

Unfortunately, it will sometimes happen that more than one people will
notice or send a patch to the same issue.
So, yeah a bit waste of time someone could think.
Thus, it is always good to check the MLs first :-).

But which MLs?
It's a pity people don't use linux-next ML for l-n releated stuff.
As a consequence, I subscribed a few hours ago to linux-next ML [2]
and will post primarily there (LKML should IMHO not be the 1st place
for such issues, but a CC is OK).

The subjects of Emails should be very clear on what type of issue.
For example, breakage(s) shoul be clearly expressed.
Also, I miss often against WTF version of linux-next ppl send patches.
Hey, hello, each l-n version has a localversion-next file, didn't see :-)?
A good subject:
"Re: linux-next: Tree for December 20 (BROKEN iwlwifi)" or
"linux-next: next-20101220 (BROKEN iwlwifi)"

That a GIT tree is compile-able is a (maybe *the*) first step to QA,
but QA is a big playground.

Hmm, I have some ideas in my big suitcase...
The wiki [1] needs partly a refresh...
An IRC-channel #linux-next would be fine...
Lemme re-think and write them down.

- Sedat -

P.S.: Personally, I have seen some patches from Randy and others which
were still not applied.

[1] http://video.linux.com/video/1048
[2] http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.ShortSummary

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Peter Hüwe]

Am Montag 20 Dezember 2010, 15:46:02 schrieb Sedat Dilek:
> > Added Stephen Rothwell on CC, maybe he can apply it directly to
> > linux-next ;)
> > 
> > Peter
> 
> I do not think this will happen for a "as-warning-classified" patch.

On arm and avr32 it is not only a warning but an error instead!

-> so the patch fixes an error / build failure which imho is quite an 
important issue.

You can see the errors in Ellerman's build farm.

http://kisskb.ellerman.id.au/kisskb/buildresult/3652816/
http://kisskb.ellerman.id.au/kisskb/buildresult/3664077/
http://kisskb.ellerman.id.au/kisskb/buildresult/3652972/
http://kisskb.ellerman.id.au/kisskb/buildresult/3664113/

As it is an error for arm and avr32 maybe it should go through their trees 
instead?

Peter

Re: [PATCH] platform/x86: Fix recursive Kconfig dependency

[Randy Dunlap]

On 12/20/10 09:09, Peter Hüwe wrote:
> Am Montag 20 Dezember 2010, 15:46:02 schrieb Sedat Dilek:
>>> Added Stephen Rothwell on CC, maybe he can apply it directly to
>>> linux-next ;)
>>>
>>> Peter
>>
>> I do not think this will happen for a "as-warning-classified" patch.
> 
> On arm and avr32 it is not only a warning but an error instead!
> 
> -> so the patch fixes an error / build failure which imho is quite an 
> important issue.
> 
> You can see the errors in Ellerman's build farm.
> 
> http://kisskb.ellerman.id.au/kisskb/buildresult/3652816/
> http://kisskb.ellerman.id.au/kisskb/buildresult/3664077/
> http://kisskb.ellerman.id.au/kisskb/buildresult/3652972/
> http://kisskb.ellerman.id.au/kisskb/buildresult/3664113/
> 
> As it is an error for arm and avr32 maybe it should go through their trees 
> instead?


It's a kconfig "error" on x86 also, but it does not stop the .config file
from being generated.  It needs to be fixed, but it's not deadly.


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts:  http://www.xenotime.net/linux/recipes/