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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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 ?
On Wed, Dec 15, 2010 at 9:35 PM, Peter Hüwe <[email protected]> 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 <[email protected]>
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
On 12/15/10 12:49, Corentin Chary wrote:
> On Wed, Dec 15, 2010 at 9:35 PM, Peter Hüwe <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
>
> 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 ***
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 <[email protected]>
Thanks,
Peter
On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <[email protected]> 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 <[email protected]>
>
> 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
Am Freitag 17 Dezember 2010, 12:30:15 schrieb Sedat Dilek:
> On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <[email protected]> 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 <[email protected]>
> >
> > Yeah, you're right - but as Sedat's patch is perfect (and fixes both) -
> > so for Sedats's patch:
> > Acked-by: Peter Huewe <[email protected]>
> >
> > 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
On Sun, Dec 19, 2010 at 8:00 PM, Peter Hüwe <[email protected]> wrote:
> Am Freitag 17 Dezember 2010, 12:30:15 schrieb Sedat Dilek:
>> On Wed, Dec 15, 2010 at 10:14 PM, Peter Hüwe <[email protected]> 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 <[email protected]>
>> >
>> > Yeah, you're right - but as Sedat's patch is perfect (and fixes both) -
>> > so for Sedats's patch:
>> > Acked-by: Peter Huewe <[email protected]>
>> >
>> > 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
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
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/