Hi Tjalling, On Thu, Jan 12, 2012 at 04:39:28PM +0100, Tjalling wrote: > On Thu, Jan 12, 2012 at 12:08, Arnaud Patard <arnaud.patard@rtp-net.org> wrote: > > Simon Guinot <simon@sequanux.org> writes: > > Hi, > > > >> Package: linux-2.6 > >> Version: 3.1.6-1 > >> Severity: important > >> > >> Dear Maintainer, > >> > >> The kernel image provided by package linux-image-3.1.0-1-kirkwood don't > >> support the LaCie Kirkwood boards. > >> > >> Please, consider applying the following patch: > >> > >> diff --git a/config/armel/config.kirkwood b/config/armel/config.kirkwood > >> index 1eae313..85b0c64 100644 > >> --- a/config/armel/config.kirkwood > >> +++ b/config/armel/config.kirkwood > >> @@ -63,6 +63,12 @@ CONFIG_MACH_DOCKSTAR=y > >> CONFIG_MACH_OPENRD_BASE=y > >> CONFIG_MACH_OPENRD_CLIENT=y > >> CONFIG_MACH_OPENRD_ULTIMATE=y > >> +CONFIG_MACH_NETSPACE_V2=y > >> +CONFIG_MACH_INETSPACE_V2=y > >> +CONFIG_MACH_NETSPACE_MAX_V2=y > >> +CONFIG_MACH_D2NET_V2=y > >> +CONFIG_MACH_NET2BIG_V2=y > >> +CONFIG_MACH_NET5BIG_V2=y > >> CONFIG_MACH_T5325=y > >> > >> ## > >> @@ -172,6 +178,11 @@ CONFIG_GPIO_SYSFS=y > >> # CONFIG_DRM is not set > >> > >> ## > >> +## file: drivers/hwmon/Kconfig > >> +## > >> +CONFIG_SENSORS_GPIO_FAN=m > >> + > >> +## > >> ## file: drivers/i2c/Kconfig > >> ## > >> CONFIG_I2C=y > >> @@ -244,6 +255,8 @@ CONFIG_ISDN_DIVAS_MAINT=m > >> CONFIG_NEW_LEDS=y > >> CONFIG_LEDS_CLASS=y > >> CONFIG_LEDS_GPIO=y > >> +CONFIG_LEDS_NS2=y > >> +CONFIG_LEDS_NETXBIG=y > >> CONFIG_LEDS_TRIGGERS=y > >> CONFIG_LEDS_TRIGGER_TIMER=y > >> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y > > > > Does this really need to be built-in ? (side note: if it can't work as > > module, why is it a tristate and not a boolean in kernel config ?) > > > It seems a bit odd that Sheeva plug, Guru plug, Dockstar, OpenRD, Qnap > and others(?) support is built-in, but support for Lacie is not. I'm > not a (kernel)developer, so I don't know what problems this will bring > up. But as a user I would appreciate it if Lacie support was in the > standard kernel. If there is any reason this is not possible, I'll > accept that off course. I think there is a misunderstanding here. Arnaud is speaking about the LED support. Build the LEDs drivers as modules is correct. Simon
Attachment:
signature.asc
Description: Digital signature