* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) @ 2010-12-08 8:17 Sedat Dilek 2010-12-08 9:12 ` Corentin Chary 0 siblings, 1 reply; 21+ messages in thread From: Sedat Dilek @ 2010-12-08 8:17 UTC (permalink / raw) To: LKML, platform-driver-x86; +Cc: Stephen Rothwell, Matthew Garrett, Randy Dunlap Hi, just wanted to build a new linux-next and see this: [ setup.log ] ... dileks.1" make -C 'debian/build/source_i386_none' O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' oldnoconfig make[2]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --oldnoconfig Kconfig 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 warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS which has unmet direct dependencies (NEW_LEDS) # # configuration written to .config # make[2]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C 'debian/build/source_i386_none' O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' prepare make[2]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile scripts/kconfig/conf --silentoldconfig Kconfig 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 warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS which has unmet direct dependencies (NEW_LEDS) Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none as source for kernel GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh make[2]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' Regards, - Sedat - ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 8:17 linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) Sedat Dilek @ 2010-12-08 9:12 ` Corentin Chary 2010-12-08 9:18 ` Sedat Dilek ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Corentin Chary @ 2010-12-08 9:12 UTC (permalink / raw) To: sedat.dilek, Matthew Garrett Cc: LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > Hi, > > just wanted to build a new linux-next and see this: > > [ setup.log ] > ... > dileks.1" make -C 'debian/build/source_i386_none' > O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' > oldnoconfig > make[2]: Entering directory > `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' > HOSTCC scripts/basic/fixdep > HOSTCC scripts/basic/docproc > GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile > HOSTCC scripts/kconfig/conf.o > HOSTCC scripts/kconfig/kxgettext.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/lex.zconf.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > scripts/kconfig/conf --oldnoconfig Kconfig > 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 > warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && > NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && > MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && > MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && > MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && > CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 > && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || > SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && > MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && > HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || > MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && > !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && > !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && > X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || > EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && > EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && > X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && > BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS > which has unmet direct dependencies (NEW_LEDS) > # > # configuration written to .config > # > make[2]: Leaving directory > `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' > env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u > LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 > DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com > DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C > 'debian/build/source_i386_none' > O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' > prepare > make[2]: Entering directory > `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' > GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile > scripts/kconfig/conf --silentoldconfig Kconfig > 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 > warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && > NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && > MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && > MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && > MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && > CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 > && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || > SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && > MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && > HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || > MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && > !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && > !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && > X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || > EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && > EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && > X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && > BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS > which has unmet direct dependencies (NEW_LEDS) > Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none > as source for kernel > GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile > CHK include/linux/version.h > UPD include/linux/version.h > CHK include/generated/utsrelease.h > UPD include/generated/utsrelease.h > CC kernel/bounds.s > GEN include/generated/bounds.h > CC arch/x86/kernel/asm-offsets.s > GEN include/generated/asm-offsets.h > CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh > make[2]: Leaving directory > `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' > make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' > > Regards, > - Sedat - > -- > To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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 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. depends: - ACPI - INPUT - EXPERIMENTAL - RFKILL - ACPI_WMI ? - HWMON ? - THERMAL ? select: - BACKLIGHT_CLASS_* - LEDS_CLASS - NEW_LEDS - INPUT_* -- Corentin Chary http://xf.iksaif.net ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:12 ` Corentin Chary @ 2010-12-08 9:18 ` Sedat Dilek 2010-12-08 9:20 ` Berg, Johannes 2010-12-08 9:28 ` Sedat Dilek ` (2 subsequent siblings) 3 siblings, 1 reply; 21+ messages in thread From: Sedat Dilek @ 2010-12-08 9:18 UTC (permalink / raw) To: Corentin Chary Cc: Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap, Johannes Berg On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary <corentin.chary@gmail.com> wrote: > On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >> Hi, >> >> just wanted to build a new linux-next and see this: >> >> [ setup.log ] >> ... >> dileks.1" make -C 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> oldnoconfig >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> HOSTCC scripts/basic/fixdep >> HOSTCC scripts/basic/docproc >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> HOSTCC scripts/kconfig/conf.o >> HOSTCC scripts/kconfig/kxgettext.o >> SHIPPED scripts/kconfig/zconf.tab.c >> SHIPPED scripts/kconfig/lex.zconf.c >> SHIPPED scripts/kconfig/zconf.hash.c >> HOSTCC scripts/kconfig/zconf.tab.o >> HOSTLD scripts/kconfig/conf >> scripts/kconfig/conf --oldnoconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> # >> # configuration written to .config >> # >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u >> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 >> DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com >> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C >> 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> prepare >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> scripts/kconfig/conf --silentoldconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none >> as source for kernel >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> CHK include/linux/version.h >> UPD include/linux/version.h >> CHK include/generated/utsrelease.h >> UPD include/generated/utsrelease.h >> CC kernel/bounds.s >> GEN include/generated/bounds.h >> CC arch/x86/kernel/asm-offsets.s >> GEN include/generated/asm-offsets.h >> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' >> >> Regards, >> - Sedat - >> -- >> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > 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 > > 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. > > depends: > - ACPI > - INPUT > - EXPERIMENTAL > - RFKILL > - ACPI_WMI ? > - HWMON ? > - THERMAL ? > > select: > - BACKLIGHT_CLASS_* > - LEDS_CLASS > - NEW_LEDS > - INPUT_* > > -- > Corentin Chary > http://xf.iksaif.net > [ CC Johannes Berg ] Cloning platform-driver-x86 GIT tree and will play with the Kconfig... Wasn't all depends/selects to LEDS_CLASS outsourced by Johannes Berg to drivers/leds/Kconfig recently? - Sedat - ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:18 ` Sedat Dilek @ 2010-12-08 9:20 ` Berg, Johannes 0 siblings, 0 replies; 21+ messages in thread From: Berg, Johannes @ 2010-12-08 9:20 UTC (permalink / raw) To: sedat.dilek@gmail.com, Corentin Chary Cc: Matthew Garrett, LKML, platform-driver-x86@vger.kernel.org, Stephen Rothwell, Randy Dunlap [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1381 bytes --] > > 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 ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:12 ` Corentin Chary 2010-12-08 9:18 ` Sedat Dilek @ 2010-12-08 9:28 ` Sedat Dilek 2010-12-08 9:51 ` Sedat Dilek 2010-12-08 9:53 ` David Woodhouse 2010-12-08 17:31 ` Randy Dunlap 3 siblings, 1 reply; 21+ messages in thread From: Sedat Dilek @ 2010-12-08 9:28 UTC (permalink / raw) To: Corentin Chary Cc: Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary <corentin.chary@gmail.com> wrote: > On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >> Hi, >> >> just wanted to build a new linux-next and see this: >> >> [ setup.log ] >> ... >> dileks.1" make -C 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> oldnoconfig >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> HOSTCC scripts/basic/fixdep >> HOSTCC scripts/basic/docproc >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> HOSTCC scripts/kconfig/conf.o >> HOSTCC scripts/kconfig/kxgettext.o >> SHIPPED scripts/kconfig/zconf.tab.c >> SHIPPED scripts/kconfig/lex.zconf.c >> SHIPPED scripts/kconfig/zconf.hash.c >> HOSTCC scripts/kconfig/zconf.tab.o >> HOSTLD scripts/kconfig/conf >> scripts/kconfig/conf --oldnoconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> # >> # configuration written to .config >> # >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u >> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 >> DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com >> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C >> 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> prepare >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> scripts/kconfig/conf --silentoldconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none >> as source for kernel >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> CHK include/linux/version.h >> UPD include/linux/version.h >> CHK include/generated/utsrelease.h >> UPD include/generated/utsrelease.h >> CC kernel/bounds.s >> GEN include/generated/bounds.h >> CC arch/x86/kernel/asm-offsets.s >> GEN include/generated/asm-offsets.h >> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' >> >> Regards, >> - Sedat - >> -- >> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > 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 > > 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. > > depends: > - ACPI > - INPUT > - EXPERIMENTAL > - RFKILL > - ACPI_WMI ? > - HWMON ? > - THERMAL ? > > select: > - BACKLIGHT_CLASS_* > - LEDS_CLASS > - NEW_LEDS > - INPUT_* > > -- > Corentin Chary > http://xf.iksaif.net > The last 3 commits touching drivers/platform/x86/Kconfig: $ git log -3 drivers/platform/x86/Kconfig commit 8c75facc93240c864bcbc9b45c492b32725ad2d4 Author: Corentin Chary <corentincj@iksaif.net> Date: Mon Nov 29 08:14:07 2010 +0100 eeepc-wmi: add rfkill support for wlan, bluetooth and 3g wimax support is missing because I don't have any DSDT with WMI and wimax support. Most of the code comes from eeepc-laptop. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com> commit 41eeea57adfb7d37b4a826877a8a6965cae5fb4a Author: Corentin Chary <corentincj@iksaif.net> Date: Mon Nov 29 08:14:06 2010 +0100 eeepc-wmi: add touchpad led support Most of the code comes from eeepc-laptop. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Matthew Garrett <mjg@redhat.com> commit 02846193f7b31e7f12a007894bdb1b4f4d7d6c22 Author: Sreedhara DS <sreedhara.ds@intel.com> Date: Fri Oct 22 15:43:55 2010 +0100 intel_scu_ipc: Utility driver for intel scu ipc ... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:28 ` Sedat Dilek @ 2010-12-08 9:51 ` Sedat Dilek 0 siblings, 0 replies; 21+ messages in thread From: Sedat Dilek @ 2010-12-08 9:51 UTC (permalink / raw) To: Corentin Chary Cc: Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap [-- Attachment #1: Type: text/plain, Size: 8614 bytes --] On Wed, Dec 8, 2010 at 10:28 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Wed, Dec 8, 2010 at 10:12 AM, Corentin Chary > <corentin.chary@gmail.com> wrote: >> On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >>> Hi, >>> >>> just wanted to build a new linux-next and see this: >>> >>> [ setup.log ] >>> ... >>> dileks.1" make -C 'debian/build/source_i386_none' >>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >>> oldnoconfig >>> make[2]: Entering directory >>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >>> HOSTCC scripts/basic/fixdep >>> HOSTCC scripts/basic/docproc >>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >>> HOSTCC scripts/kconfig/conf.o >>> HOSTCC scripts/kconfig/kxgettext.o >>> SHIPPED scripts/kconfig/zconf.tab.c >>> SHIPPED scripts/kconfig/lex.zconf.c >>> SHIPPED scripts/kconfig/zconf.hash.c >>> HOSTCC scripts/kconfig/zconf.tab.o >>> HOSTLD scripts/kconfig/conf >>> scripts/kconfig/conf --oldnoconfig Kconfig >>> 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 >>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >>> which has unmet direct dependencies (NEW_LEDS) >>> # >>> # configuration written to .config >>> # >>> make[2]: Leaving directory >>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >>> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u >>> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 >>> DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com >>> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C >>> 'debian/build/source_i386_none' >>> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >>> prepare >>> make[2]: Entering directory >>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >>> scripts/kconfig/conf --silentoldconfig Kconfig >>> 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 >>> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >>> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >>> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >>> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >>> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >>> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >>> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >>> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >>> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >>> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >>> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >>> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >>> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >>> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >>> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >>> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >>> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >>> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >>> which has unmet direct dependencies (NEW_LEDS) >>> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none >>> as source for kernel >>> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >>> CHK include/linux/version.h >>> UPD include/linux/version.h >>> CHK include/generated/utsrelease.h >>> UPD include/generated/utsrelease.h >>> CC kernel/bounds.s >>> GEN include/generated/bounds.h >>> CC arch/x86/kernel/asm-offsets.s >>> GEN include/generated/asm-offsets.h >>> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh >>> make[2]: Leaving directory >>> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >>> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' >>> >>> Regards, >>> - Sedat - >>> -- >>> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> 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 >> >> 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. >> >> depends: >> - ACPI >> - INPUT >> - EXPERIMENTAL >> - RFKILL >> - ACPI_WMI ? >> - HWMON ? >> - THERMAL ? >> >> select: >> - BACKLIGHT_CLASS_* >> - LEDS_CLASS >> - NEW_LEDS >> - INPUT_* >> >> -- >> Corentin Chary >> http://xf.iksaif.net >> > > The last 3 commits touching drivers/platform/x86/Kconfig: > > $ git log -3 drivers/platform/x86/Kconfig > > commit 8c75facc93240c864bcbc9b45c492b32725ad2d4 > Author: Corentin Chary <corentincj@iksaif.net> > Date: Mon Nov 29 08:14:07 2010 +0100 > > eeepc-wmi: add rfkill support for wlan, bluetooth and 3g > > wimax support is missing because I don't have any DSDT > with WMI and wimax support. > > Most of the code comes from eeepc-laptop. > > Signed-off-by: Corentin Chary <corentincj@iksaif.net> > Signed-off-by: Matthew Garrett <mjg@redhat.com> > > commit 41eeea57adfb7d37b4a826877a8a6965cae5fb4a > Author: Corentin Chary <corentincj@iksaif.net> > Date: Mon Nov 29 08:14:06 2010 +0100 > > eeepc-wmi: add touchpad led support > > Most of the code comes from eeepc-laptop. > > Signed-off-by: Corentin Chary <corentincj@iksaif.net> > Signed-off-by: Matthew Garrett <mjg@redhat.com> > > commit 02846193f7b31e7f12a007894bdb1b4f4d7d6c22 > Author: Sreedhara DS <sreedhara.ds@intel.com> > Date: Fri Oct 22 15:43:55 2010 +0100 > > intel_scu_ipc: Utility driver for intel scu ipc > ... > The following patch fixes the issue here (setup.log attached). - Sedat - [-- Attachment #2: platform-x86-Kconfig-Replace-select-by-depends-on-ACPI_WMI.patch --] [-- Type: plain/text, Size: 764 bytes --] [-- Attachment #3: setup.log --] [-- Type: application/octet-stream, Size: 9713 bytes --] make -f debian/rules.real setup-flavour ABINAME='' ARCH='i386' COMPILER='gcc-4.4' FEATURESET='none' FLAVOUR='686' INITRD_CMD='update-initramfs' KCONFIG='debian/config/config debian/config/kernelarch-x86/config debian/config/kernelarch-x86/config-arch-32 debian/config/i386/none/config.686' KERNEL_ARCH='x86' LOCALVERSION='-686' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-686' MAJOR='2.6' MODULES='True' SOURCEVERSION='2.6.37~rc5-1~next20101208.dileks.1' TYPE='plain' UPSTREAMVERSION='2.6.37-rc5' VERSION='2.6.37' make[1]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' rm -rf 'debian/build/source' mkdir -p 'debian/build/source' cp -al arch block COPYING CREDITS crypto Documentation drivers firmware fs include init ipc Kbuild Kconfig kernel lib MAINTAINERS Makefile mm net README REPORTING-BUGS samples scripts security sound tools usr virt .gitignore .mailmap 'debian/build/source' cd 'debian/build/source'; python '/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/bin/patch.apply' --overwrite-home='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/patches' /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/bin/patch.apply:81: DeprecationWarning: functions overriding warnings.showwarning() must support the 'line' argument warn('No %s file, assuming Debian Linux %s' % (self._file, upstream)) Warning: No version.Debian file, assuming Debian Linux 2.6.37~rc5 --> Try to apply base. (+) OK linux-next/patch-v2.6.37-rc5-next-20101208 (+) OK linux-next/0001-Remove-localversion-next.patch (+) OK from-johill/001-debug-section-mismatch.patch (+) OK platform-x86-fix/platform-x86-Kconfig-Replace-select-by-depends-on-ACPI_WMI.patch (+) OK wq-for-linus/workqueue-check-the-allocation-of-system_unbound_wq.patch (+) OK mm-fix/cgroup-Avoid-a-memset-by-using-vzalloc.patch (+) OK mm-fix/kmemleak-remove-memset-by-using-kzalloc.patch (+) OK ACPI-PM/1-13-ACPI-PM-Check-device-state-before-refcounting-power-resources.patch (+) OK ACPI-PM/2-13-ACPI-PM-Do-not-refcount-power-resources-that-can-t-be-turned-on.patch (+) OK ACPI-PM/3-13-ACPI-PM-Prevent-acpi_power_get_inferred_state-from-making-changes.patch (+) OK ACPI-PM/4-13-ACPI-PM-Add-functions-for-manipulating-lists-of-power-resources.patch (+) OK ACPI-PM/5-13-ACPI-PM-Introduce-function-for-refcounting-device-power-resources.patch (+) OK ACPI-PM/6-13-ACPI-PM-Introduce-__acpi_bus_get_power.patch (+) OK ACPI-PM/7-13-ACPI-PM-Add-function-for-device-power-state-initialization.patch (+) OK ACPI-PM/8-13-ACPI-PM-Add-function-for-updating-device-power-state-consistently.patch (+) OK ACPI-PM/9-13-ACPI-PM-Register-acpi_power_driver-early.patch (+) OK ACPI-PM/10-13-ACPI-PM-Register-power-resource-devices-as-soon-as-they-are-needed.patch (+) OK ACPI-PM/11-13-ACPI-Fan-Rework-the-handling-of-power-resources.patch (+) OK ACPI-PM/12-13-ACPI-PM-Drop-acpi_bus_get_power.patch (+) OK ACPI-PM/13-13-ACPI-PM-Drop-acpi_power_nocheck.patch (+) OK ACPI-PM-fix/Platform-x86-Make-fujitsu_laptop-use-acpi_bus_update_power.patch (+) OK vfs-scale-working/vfs-scale-working.patch (+) OK from-npiggin/fs-namei-fix-by-npiggin-v2-linux-next-20101208.patch (+) OK ext4-fix/ext4-fix-possible-overflow-in-ext4_trim_fs.patch (+) OK danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch (+) OK danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch (+) OK danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch (+) OK danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch (+) OK danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch (+) OK danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch (+) OK danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch (+) OK danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch (+) OK danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch (+) OK danvet-radeon-asic-header-cleanup-2/1-7-radeon-consolidate-asic-specific-function-decls-for-pre-r600.patch (+) OK danvet-radeon-asic-header-cleanup-2/2-7-radeon-consolidate-asic-specific-function-decls-for-r600-later.patch (+) OK danvet-radeon-asic-header-cleanup-2/3-7-radeon-drop-extern-from-function-decls.patch (+) OK danvet-radeon-asic-header-cleanup-2/4-7-radeon-kill-decls-for-inline-functions.patch (+) OK danvet-radeon-asic-header-cleanup-2/5-7-radeon-move-blit-functions-to-radeon_asic.h.patch (+) OK danvet-radeon-asic-header-cleanup-2/6-7-radeon-kill-r100_io_-r-w-reg.patch (+) OK danvet-radeon-asic-header-cleanup-2/7-7-radeon-kill-rdev--pciep_-r-w-reg.patch (+) OK for-drm-radeon-testing/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch (+) OK dri-devel/drm-radeon-kms-improve-pflip-precision-on-r1xx-r4xx.patch (+) OK dri-devel/drm-Add-missing-drm_vblank_put-along-queue-vblank-error-path.patch (+) OK ath5k-fix/0001-ath5k-Fix-modinfo-does-not-list-alias-pci-id-lines.patch (+) OK debian/version.patch (+) OK debian/kernelvariables-2.6.37.patch (+) OK debian/doc-build-parallel.patch (+) OK bugfix/ia64/hardcode-arch-script-output.patch (+) OK bugfix/mips/disable-advansys.patch (+) OK bugfix/arm/disable-scsi_acard.patch (+) OK debian/mips-disable-werror.patch (+) OK bugfix/powerpc/lpar-console.patch (+) OK features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch (+) OK debian/arch-sh4-fix-uimage-build.patch (+) OK bugfix/mips/mips-ide-flush-dcache.patch (+) OK bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch (+) OK bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch --> base fully applied. # Suppress trailing '+' in utsrelease touch 'debian/build/source/.scmversion' rm -rf 'debian/build/source_i386_none' cp -al 'debian/build/source' 'debian/build/source_i386_none' cd 'debian/build/source_i386_none'; python '/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/bin/patch.apply' --overwrite-home='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/patches' -a i386 -f none --> Try to apply base-extra. --> base-extra fully applied. python debian/bin/kconfig.py 'debian/build/config.i386_none_686' debian/config/config debian/config/kernelarch-x86/config debian/config/kernelarch-x86/config-arch-32 debian/config/i386/none/config.686 rm -rf 'debian/build/build_i386_none_686' mkdir 'debian/build/build_i386_none_686' cp 'debian/build/config.i386_none_686' 'debian/build/build_i386_none_686/.config' echo '-686' > 'debian/build/build_i386_none_686/localversion' echo 'override ARCH = x86' >> 'debian/build/build_i386_none_686/.kernelvariables' echo 'CCACHE = ccache' >> 'debian/build/build_i386_none_686/.kernelvariables' echo 'CC = $(if $(DEBIAN_KERNEL_USE_CCACHE),$(CCACHE)) $(CROSS_COMPILE)gcc-4.4' >> 'debian/build/build_i386_none_686/.kernelvariables' echo 'ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))' >> 'debian/build/build_i386_none_686/.kernelvariables' echo 'override CROSS_COMPILE = $(DEB_HOST_GNU_TYPE)-' >> 'debian/build/build_i386_none_686/.kernelvariables' echo 'endif' >> 'debian/build/build_i386_none_686/.kernelvariables' env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C 'debian/build/source_i386_none' O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' oldnoconfig make[2]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --oldnoconfig Kconfig # # configuration written to .config # make[2]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C 'debian/build/source_i386_none' O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' prepare make[2]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile scripts/kconfig/conf --silentoldconfig Kconfig Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none as source for kernel GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h CC kernel/bounds.s GEN include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh make[2]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:12 ` Corentin Chary 2010-12-08 9:18 ` Sedat Dilek 2010-12-08 9:28 ` Sedat Dilek @ 2010-12-08 9:53 ` David Woodhouse 2010-12-08 10:12 ` Sedat Dilek 2010-12-08 17:46 ` Dmitry Torokhov 2010-12-08 17:31 ` Randy Dunlap 3 siblings, 2 replies; 21+ messages in thread From: David Woodhouse @ 2010-12-08 9:53 UTC (permalink / raw) To: Corentin Chary Cc: sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: > > 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. A better policy is: "NEVER USE SELECT". -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:53 ` David Woodhouse @ 2010-12-08 10:12 ` Sedat Dilek 2010-12-08 17:46 ` Dmitry Torokhov 1 sibling, 0 replies; 21+ messages in thread From: Sedat Dilek @ 2010-12-08 10:12 UTC (permalink / raw) To: David Woodhouse Cc: Corentin Chary, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap On Wed, Dec 8, 2010 at 10:53 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: >> >> 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. > > A better policy is: "NEVER USE SELECT". Yes, confirmed (see my patch to MLs). - Sedat - ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:53 ` David Woodhouse 2010-12-08 10:12 ` Sedat Dilek @ 2010-12-08 17:46 ` Dmitry Torokhov 2010-12-08 21:51 ` Randy Dunlap 1 sibling, 1 reply; 21+ messages in thread From: Dmitry Torokhov @ 2010-12-08 17:46 UTC (permalink / raw) To: David Woodhouse Cc: Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell, Randy Dunlap On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote: > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: > > > > 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. > > A better policy is: "NEVER USE SELECT". > No, this is BS. User selecting, for example, a button driver should not care that it is working in polling mode only and needs polled device library to work. As it was said before, drivers need to depend on major subsystems and select minors and library modules. The fact that our Kconfig can't really provide us with the functionality we desire (be it because the logic is fuzzy and hard to formalize or some other reason) shoud not force "NO SELECT" policy, we just need to be careful when using it. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 17:46 ` Dmitry Torokhov @ 2010-12-08 21:51 ` Randy Dunlap 2010-12-08 22:12 ` Dmitry Torokhov 2010-12-08 23:08 ` David Woodhouse 0 siblings, 2 replies; 21+ messages in thread From: Randy Dunlap @ 2010-12-08 21:51 UTC (permalink / raw) To: Dmitry Torokhov Cc: David Woodhouse, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote: > On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote: > > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: > > > > > > 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. > > > > A better policy is: "NEVER USE SELECT". > > > > No, this is BS. User selecting, for example, a button driver should not > care that it is working in polling mode only and needs polled device > library to work. As it was said before, drivers need to depend on major > subsystems and select minors and library modules. I dislike select, but reality is that modules do need to select/enable library code and minor features sometimes. OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" to enable an entire subsystem is wrong and bad IMO. > The fact that our Kconfig can't really provide us with the functionality > we desire (be it because the logic is fuzzy and hard to formalize or > some other reason) shoud not force "NO SELECT" policy, we just need to > be careful when using it. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 21:51 ` Randy Dunlap @ 2010-12-08 22:12 ` Dmitry Torokhov 2010-12-08 22:37 ` Thadeu Lima de Souza Cascardo 2010-12-08 23:08 ` David Woodhouse 1 sibling, 1 reply; 21+ messages in thread From: Dmitry Torokhov @ 2010-12-08 22:12 UTC (permalink / raw) To: Randy Dunlap Cc: David Woodhouse, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, Dec 08, 2010 at 01:51:05PM -0800, Randy Dunlap wrote: > On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote: > > > On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote: > > > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: > > > > > > > > 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. > > > > > > A better policy is: "NEVER USE SELECT". > > > > > > > No, this is BS. User selecting, for example, a button driver should not > > care that it is working in polling mode only and needs polled device > > library to work. As it was said before, drivers need to depend on major > > subsystems and select minors and library modules. > > I dislike select, but reality is that modules do need to select/enable > library code and minor features sometimes. > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > to enable an entire subsystem is wrong and bad IMO. I am 50/50 here. On one hand selecting whole subsystems may not be the best option, on the other hand (depending on how Kconfig is organized) it might make sense. Consider you have an USB joystick. You are in input, in joystick sub-menu, which comes _before_ USB. If you happen to have USB disabled then you, with your scheme, will not see the entry for the joystick. You will have to go into USB menu, activate USB and then go back and scan menus that you already been to for any new options. And again, and again. Not very friendly and so right now USB input devices do depend on INPUT, select USB and depend on USB_ARCH_HAS_HCD (to make sure USB can be activated). Also, in case of CMPC, the user wants to support _all_ features of his/her laptop which is kind of useless without input, right? -- Dmitry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 22:12 ` Dmitry Torokhov @ 2010-12-08 22:37 ` Thadeu Lima de Souza Cascardo 0 siblings, 0 replies; 21+ messages in thread From: Thadeu Lima de Souza Cascardo @ 2010-12-08 22:37 UTC (permalink / raw) To: Dmitry Torokhov Cc: Randy Dunlap, David Woodhouse, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell [-- Attachment #1: Type: text/plain, Size: 3376 bytes --] On Wed, Dec 08, 2010 at 02:12:17PM -0800, Dmitry Torokhov wrote: > On Wed, Dec 08, 2010 at 01:51:05PM -0800, Randy Dunlap wrote: > > On Wed, 8 Dec 2010 09:46:04 -0800 Dmitry Torokhov wrote: > > > > > On Wed, Dec 08, 2010 at 09:53:09AM +0000, David Woodhouse wrote: > > > > On Wed, 2010-12-08 at 10:12 +0100, Corentin Chary wrote: > > > > > > > > > > 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. > > > > > > > > A better policy is: "NEVER USE SELECT". > > > > > > > > > > No, this is BS. User selecting, for example, a button driver should not > > > care that it is working in polling mode only and needs polled device > > > library to work. As it was said before, drivers need to depend on major > > > subsystems and select minors and library modules. > > > > I dislike select, but reality is that modules do need to select/enable > > library code and minor features sometimes. > > > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > > to enable an entire subsystem is wrong and bad IMO. > > I am 50/50 here. On one hand selecting whole subsystems may not be the > best option, on the other hand (depending on how Kconfig is organized) > it might make sense. Consider you have an USB joystick. You are in > input, in joystick sub-menu, which comes _before_ USB. If you happen to > have USB disabled then you, with your scheme, will not see the entry for > the joystick. You will have to go into USB menu, activate USB and then > go back and scan menus that you already been to for any new options. And > again, and again. Not very friendly and so right now USB input devices > do depend on INPUT, select USB and depend on USB_ARCH_HAS_HCD (to make > sure USB can be activated). > > Also, in case of CMPC, the user wants to support _all_ features of > his/her laptop which is kind of useless without input, right? Thanks, Dmitry, for building the case for CMPC. Besides input devices, classmate-laptop only supports a single rfkill device. Currently, using the driver without rfkill support is possible. That's not the case when the input subsystem is disabled. I would like the user to go the the platform/x86 menu and say 'hey, classmate support'. That would however, be an argument for using select for everything, or making depends work just like some dependencies resolvers work in package management systems, like apt. OTOH, that would imply in lots of undesired questions when someone does not want to enable anything that depends on USB (or any bus or subsystem) at all. For the case of CMPC, the user has already entered the platform/x86 menu. The CMPC option will not be visible if INPUT has been disabled. And select works just fine here, since INPUT does not depend on anything. OTOH, INPUT can only be disabled if EMBEDDED is enabled. And if the user has done that, user must know what user is doing. So, if the rule of thumb is that major subsystems should not be selected, I'd be willing to submit of ack a patch fixing that. Regards, Cascardo. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 21:51 ` Randy Dunlap 2010-12-08 22:12 ` Dmitry Torokhov @ 2010-12-08 23:08 ` David Woodhouse 2010-12-08 23:31 ` Dmitry Torokhov 2010-12-08 23:34 ` Randy Dunlap 1 sibling, 2 replies; 21+ messages in thread From: David Woodhouse @ 2010-12-08 23:08 UTC (permalink / raw) To: Randy Dunlap Cc: Dmitry Torokhov, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote: > > I dislike select, but reality is that modules do need to select/enable > library code and minor features sometimes. > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > to enable an entire subsystem is wrong and bad IMO. This is just a deficiency in the tools. The correct answer is to fix the damn tools, not invent this silly 'select' facility which means much the same thing as 'depends on' but is implemented differently. As long ago as the mid-1990s, the Nemesis research OS was using a tcl xconfig tool based on the Linux one, but which would show you the dependencies for an option that was disabled, so you could enable them where you needed to. Rather than just hiding the option completely. -- dwmw2 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:08 ` David Woodhouse @ 2010-12-08 23:31 ` Dmitry Torokhov 2010-12-08 23:35 ` David Woodhouse 2010-12-08 23:34 ` Randy Dunlap 1 sibling, 1 reply; 21+ messages in thread From: Dmitry Torokhov @ 2010-12-08 23:31 UTC (permalink / raw) To: David Woodhouse Cc: Randy Dunlap, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, Dec 08, 2010 at 11:08:39PM +0000, David Woodhouse wrote: > On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote: > > > > I dislike select, but reality is that modules do need to select/enable > > library code and minor features sometimes. > > > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > > to enable an entire subsystem is wrong and bad IMO. > > This is just a deficiency in the tools. The correct answer is to fix the > damn tools, not invent this silly 'select' facility which means much the > same thing as 'depends on' but is implemented differently. > > As long ago as the mid-1990s, the Nemesis research OS was using a tcl > xconfig tool based on the Linux one, but which would show you the > dependencies for an option that was disabled, so you could enable them > where you needed to. Rather than just hiding the option completely. Even better tool would allow selecting the needed optios right there, without the need of moving away from teh current option. And yet better tool would not even ask user and enable them on its own. Hey, but we have it! It's called "select". Seriously, select is dangerous. I wonder if a rule like "One can only select a symbol whose dependencies are all satisfied by the current symbol and/or its parents and the symbols they select or depend on" would not make select safe enough. -- Dmitry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:31 ` Dmitry Torokhov @ 2010-12-08 23:35 ` David Woodhouse 2010-12-08 23:49 ` Dmitry Torokhov 0 siblings, 1 reply; 21+ messages in thread From: David Woodhouse @ 2010-12-08 23:35 UTC (permalink / raw) To: Dmitry Torokhov Cc: Randy Dunlap, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote: > Even better tool would allow selecting the needed optios right there, > without the need of moving away from teh current option. That's exactly what the Nemesis version of xconfig did, almost 15 years ago. > And yet better tool would not even ask user and enable them on its > own. Hey, but we have it! It's called "select". The tools could do that with 'depends on' too. Why make a distinction? > Seriously, select is dangerous. I wonder if a rule like "One can only > select a symbol whose dependencies are all satisfied by the current > symbol and/or its parents and the symbols they select or depend on" > would not make select safe enough. "One can only select a symbol which isn't otherwise presented to the user as a choice". So things like CONFIG_REED_SOLOMON are fine to be selected, because the user would never see it anyway. Otherwise, just use depends. And if that's a problem for you, fix the damn tools. -- dwmw2 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:35 ` David Woodhouse @ 2010-12-08 23:49 ` Dmitry Torokhov 2010-12-08 23:58 ` Randy Dunlap 0 siblings, 1 reply; 21+ messages in thread From: Dmitry Torokhov @ 2010-12-08 23:49 UTC (permalink / raw) To: David Woodhouse Cc: Randy Dunlap, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, Dec 08, 2010 at 11:35:08PM +0000, David Woodhouse wrote: > On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote: > > Even better tool would allow selecting the needed optios right there, > > without the need of moving away from teh current option. > > That's exactly what the Nemesis version of xconfig did, almost 15 years > ago. > > > And yet better tool would not even ask user and enable them on its > > own. Hey, but we have it! It's called "select". > > The tools could do that with 'depends on' too. Why make a distinction? To allow automatic/manual selection. Sometimes the only answer to "shoudl it be enabled" is "Yes". I.e. drivers that need polling need input-polldev support. There is no reason whatsoever to even ask user. Same thing for platform drivers. "Don't you also want to enable option for your keyboard and mouse to work? Go do that, you won't regret." "Well, duh!" > > > Seriously, select is dangerous. I wonder if a rule like "One can only > > select a symbol whose dependencies are all satisfied by the current > > symbol and/or its parents and the symbols they select or depend on" > > would not make select safe enough. > > "One can only select a symbol which isn't otherwise presented to the > user as a choice". Input-polldev _is_ presented as a choice in case user or distro want to use out of tree driver that depends on it. Does this mean we shoudl disallow selects on it? I don't think so. > So things like CONFIG_REED_SOLOMON are fine to be selected, because the > user would never see it anyway. > > Otherwise, just use depends. And if that's a problem for you, fix the > damn tools. Yep, starting with kconfig. -- Dmitry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:49 ` Dmitry Torokhov @ 2010-12-08 23:58 ` Randy Dunlap 0 siblings, 0 replies; 21+ messages in thread From: Randy Dunlap @ 2010-12-08 23:58 UTC (permalink / raw) To: Dmitry Torokhov Cc: David Woodhouse, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On 12/08/10 15:49, Dmitry Torokhov wrote: > On Wed, Dec 08, 2010 at 11:35:08PM +0000, David Woodhouse wrote: >> On Wed, 2010-12-08 at 15:31 -0800, Dmitry Torokhov wrote: >>> Even better tool would allow selecting the needed optios right there, >>> without the need of moving away from teh current option. >> >> That's exactly what the Nemesis version of xconfig did, almost 15 years >> ago. >> >>> And yet better tool would not even ask user and enable them on its >>> own. Hey, but we have it! It's called "select". >> >> The tools could do that with 'depends on' too. Why make a distinction? > > To allow automatic/manual selection. Sometimes the only answer to > "shoudl it be enabled" is "Yes". I.e. drivers that need polling need > input-polldev support. There is no reason whatsoever to even ask user. > > Same thing for platform drivers. "Don't you also want to enable option for > your keyboard and mouse to work? Go do that, you won't regret." "Well, > duh!" > >> >>> Seriously, select is dangerous. I wonder if a rule like "One can only >>> select a symbol whose dependencies are all satisfied by the current >>> symbol and/or its parents and the symbols they select or depend on" >>> would not make select safe enough. >> >> "One can only select a symbol which isn't otherwise presented to the >> user as a choice". > > Input-polldev _is_ presented as a choice in case user or distro want to > use out of tree driver that depends on it. Does this mean we shoudl > disallow selects on it? I don't think so. To me it means that we have too many config options, but I'm sure that some embedded people would disagree with that. | GUI tools have means of presenting this, menuconfig and oldconfig have | harder time... Sure, I know that. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:08 ` David Woodhouse 2010-12-08 23:31 ` Dmitry Torokhov @ 2010-12-08 23:34 ` Randy Dunlap 2010-12-08 23:41 ` David Woodhouse 2010-12-08 23:52 ` Dmitry Torokhov 1 sibling, 2 replies; 21+ messages in thread From: Randy Dunlap @ 2010-12-08 23:34 UTC (permalink / raw) To: David Woodhouse Cc: Dmitry Torokhov, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, 08 Dec 2010 23:08:39 +0000 David Woodhouse wrote: > On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote: > > > > I dislike select, but reality is that modules do need to select/enable > > library code and minor features sometimes. > > > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > > to enable an entire subsystem is wrong and bad IMO. > > This is just a deficiency in the tools. The correct answer is to fix the > damn tools, not invent this silly 'select' facility which means much the > same thing as 'depends on' but is implemented differently. > > As long ago as the mid-1990s, the Nemesis research OS was using a tcl > xconfig tool based on the Linux one, but which would show you the > dependencies for an option that was disabled, so you could enable them > where you needed to. Rather than just hiding the option completely. xconfig has options that show all symbols. I use that most of the time, but I bet that most people do not. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:34 ` Randy Dunlap @ 2010-12-08 23:41 ` David Woodhouse 2010-12-08 23:52 ` Dmitry Torokhov 1 sibling, 0 replies; 21+ messages in thread From: David Woodhouse @ 2010-12-08 23:41 UTC (permalink / raw) To: Randy Dunlap Cc: Dmitry Torokhov, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, 2010-12-08 at 15:34 -0800, Randy Dunlap wrote: > xconfig has options that show all symbols. I use that most of the time, > but I bet that most people do not. That just means that 'select' is *completely* pointless and stupid, rather than being a lazy workaround for broken tools. Time to remove it *entirely*, perhaps? -- dwmw2 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 23:34 ` Randy Dunlap 2010-12-08 23:41 ` David Woodhouse @ 2010-12-08 23:52 ` Dmitry Torokhov 1 sibling, 0 replies; 21+ messages in thread From: Dmitry Torokhov @ 2010-12-08 23:52 UTC (permalink / raw) To: Randy Dunlap Cc: David Woodhouse, Corentin Chary, sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On Wed, Dec 08, 2010 at 03:34:28PM -0800, Randy Dunlap wrote: > On Wed, 08 Dec 2010 23:08:39 +0000 David Woodhouse wrote: > > > On Wed, 2010-12-08 at 13:51 -0800, Randy Dunlap wrote: > > > > > > I dislike select, but reality is that modules do need to select/enable > > > library code and minor features sometimes. > > > > > > OTOH, where drivers/platform/x86/Kconfig:ACPI_CMPC does "select INPUT" > > > to enable an entire subsystem is wrong and bad IMO. > > > > This is just a deficiency in the tools. The correct answer is to fix the > > damn tools, not invent this silly 'select' facility which means much the > > same thing as 'depends on' but is implemented differently. > > > > As long ago as the mid-1990s, the Nemesis research OS was using a tcl > > xconfig tool based on the Linux one, but which would show you the > > dependencies for an option that was disabled, so you could enable them > > where you needed to. Rather than just hiding the option completely. > > > xconfig has options that show all symbols. I use that most of the time, > but I bet that most people do not. > GUI tools have means of presenting this, menuconfig and oldconfig have harder time... -- Dmitry ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) 2010-12-08 9:12 ` Corentin Chary ` (2 preceding siblings ...) 2010-12-08 9:53 ` David Woodhouse @ 2010-12-08 17:31 ` Randy Dunlap 3 siblings, 0 replies; 21+ messages in thread From: Randy Dunlap @ 2010-12-08 17:31 UTC (permalink / raw) To: Corentin Chary Cc: sedat.dilek, Matthew Garrett, LKML, platform-driver-x86, Stephen Rothwell On 12/08/10 01:12, Corentin Chary wrote: > On Wed, Dec 8, 2010 at 9:17 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote: >> Hi, >> >> just wanted to build a new linux-next and see this: >> >> [ setup.log ] >> ... >> dileks.1" make -C 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> oldnoconfig >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> HOSTCC scripts/basic/fixdep >> HOSTCC scripts/basic/docproc >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> HOSTCC scripts/kconfig/conf.o >> HOSTCC scripts/kconfig/kxgettext.o >> SHIPPED scripts/kconfig/zconf.tab.c >> SHIPPED scripts/kconfig/lex.zconf.c >> SHIPPED scripts/kconfig/zconf.hash.c >> HOSTCC scripts/kconfig/zconf.tab.o >> HOSTLD scripts/kconfig/conf >> scripts/kconfig/conf --oldnoconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> # >> # configuration written to .config >> # >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u >> LOCALVERSION DISTRIBUTION_OFFICIAL_BUILD=1 >> DISTRIBUTION_UPLOADER=sedat.dilek@gmail.com >> DISTRIBUTION_VERSION="2.6.37~rc5-1~next20101208.dileks.1" make -C >> 'debian/build/source_i386_none' >> O='/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686' >> prepare >> make[2]: Entering directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> scripts/kconfig/conf --silentoldconfig Kconfig >> 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 >> warning: (ADB_PMU_LED && MACINTOSH_DRIVERS && ADB_PMU || ATH5K && >> NETDEVICES && WLAN && ATH_COMMON && (PCI || ATHEROS_AR231X) && >> MAC80211 || ATH9K && NETDEVICES && WLAN && ATH_COMMON && PCI && >> MAC80211 || ATH9K_HTC && NETDEVICES && WLAN && ATH_COMMON && USB && >> MAC80211 || CARL9170_LEDS && NETDEVICES && WLAN && ATH_COMMON && >> CARL9170 || INPUT_WISTRON_BTNS && !S390 && INPUT && INPUT_MISC && X86 >> && !X86_64 || SENSORS_APPLESMC && HWMON && INPUT && X86 || >> SENSORS_LIS3LV02D && HWMON && ACPI && INPUT || IR_WINBOND_CIR && >> MEDIA_SUPPORT && X86 && PNP && RC_CORE || BACKLIGHT_ADP8860 && >> HAS_IOMEM && BACKLIGHT_LCD_SUPPORT && BACKLIGHT_CLASS_DEVICE && I2C || >> MSM_STAGING && STAGING && !STAGING_EXCLUDE_BUILD && FB && ARCH_MSM && >> !FB_MSM || ASUS_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && >> !ACPI_ASUS && INPUT && (RFKILL || RFKILL=n) || THINKPAD_ACPI && X86 && >> X86_PLATFORM_DEVICES && ACPI && INPUT && (RFKILL || RFKILL=n) || >> EEEPC_LAPTOP && X86 && X86_PLATFORM_DEVICES && ACPI && INPUT && >> EXPERIMENTAL && (RFKILL || RFKILL=n) && HOTPLUG_PCI || EEEPC_WMI && >> X86 && X86_PLATFORM_DEVICES && ACPI_WMI && INPUT && EXPERIMENTAL && >> BACKLIGHT_CLASS_DEVICE && (RFKILL || RFKILL=n)) selects LEDS_CLASS >> which has unmet direct dependencies (NEW_LEDS) >> Using /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none >> as source for kernel >> GEN /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/build_i386_none_686/Makefile >> CHK include/linux/version.h >> UPD include/linux/version.h >> CHK include/generated/utsrelease.h >> UPD include/generated/utsrelease.h >> CC kernel/bounds.s >> GEN include/generated/bounds.h >> CC arch/x86/kernel/asm-offsets.s >> GEN include/generated/asm-offsets.h >> CALL /home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none/scripts/checksyscalls.sh >> make[2]: Leaving directory >> `/home/sd/src/linux-2.6/linux-2.6.37-rc5/debian/build/source_i386_none' >> make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc5' >> >> Regards, >> - Sedat - >> -- >> To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > 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 > > I don't really see how it's a recursive dependency, but maybe it's > time to clean this KConfig. It's circular. > What is our current policy about that ? Documentation/kbuild/kconfig-language.txt says: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. I think that it would help if all of drivers/platform/x86/Kconfig treated ACPI_WMI the same way. Currently 2 drivers select it and 4 drivers depend on it. Ah, that's what Sedat's patch does. Good. > 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. > > depends: > - ACPI > - INPUT > - EXPERIMENTAL > - RFKILL > - ACPI_WMI ? > - HWMON ? > - THERMAL ? > > select: > - BACKLIGHT_CLASS_* > - LEDS_CLASS > - NEW_LEDS > - INPUT_* > -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-12-09 0:35 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-08 8:17 linux-next: Tree for December 8 (drivers/platform/x86/Kconfig:422:error: recursive dependency detected!) Sedat Dilek 2010-12-08 9:12 ` Corentin Chary 2010-12-08 9:18 ` Sedat Dilek 2010-12-08 9:20 ` Berg, Johannes 2010-12-08 9:28 ` Sedat Dilek 2010-12-08 9:51 ` Sedat Dilek 2010-12-08 9:53 ` David Woodhouse 2010-12-08 10:12 ` Sedat Dilek 2010-12-08 17:46 ` Dmitry Torokhov 2010-12-08 21:51 ` Randy Dunlap 2010-12-08 22:12 ` Dmitry Torokhov 2010-12-08 22:37 ` Thadeu Lima de Souza Cascardo 2010-12-08 23:08 ` David Woodhouse 2010-12-08 23:31 ` Dmitry Torokhov 2010-12-08 23:35 ` David Woodhouse 2010-12-08 23:49 ` Dmitry Torokhov 2010-12-08 23:58 ` Randy Dunlap 2010-12-08 23:34 ` Randy Dunlap 2010-12-08 23:41 ` David Woodhouse 2010-12-08 23:52 ` Dmitry Torokhov 2010-12-08 17:31 ` Randy Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox