[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C5C86A19469DAE48AAAD0E5F3716E44501D5E1D585@irsmsx504.ger.corp.intel.com>
Date: Wed, 8 Dec 2010 09:20:43 +0000
From: "Berg, Johannes" <johannes.berg@...el.com>
To: "sedat.dilek@...il.com" <sedat.dilek@...il.com>,
Corentin Chary <corentin.chary@...il.com>
CC: Matthew Garrett <mjg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
"platform-driver-x86@...r.kernel.org"
<platform-driver-x86@...r.kernel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Randy Dunlap <randy.dunlap@...cle.com>
Subject: RE: linux-next: Tree for December 8
(drivers/platform/x86/Kconfig:422:error: recursive dependency detected!)
> > Hum ...
> > ACER_WMI:
> > select ACPI_WMI
> > depends on LEDS_CLASS
> > depends on NEW_LEDS
> >
> > EEEPC_WMI:
> > depends on ACPI_WMI
> > select LEDS_CLASS
> > select NEW_LEDS
Curious.
> > I don't really see how it's a recursive dependency, but maybe it's
> > time to clean this KConfig.
> > What is our current policy about that ?
> >
> > I think we should *depends* on important subsystem (ACPI, INPUT, ...)
> > and select obscure things so
> > that the driver does not get lost if you don't enable the leds.
I'm happy with that. Frankly, I don't want to care about LED, but...
> Wasn't all depends/selects to LEDS_CLASS outsourced by Johannes Berg
> to drivers/leds/Kconfig recently?
No, I just cleaned it up to make it not break builds and disallow
some weird configurations.
johannes
--------------------------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
Powered by blists - more mailing lists