2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Arnd Hannemann]

Hi,

with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31

relevant dmesg output of 2.6.33-rc3:

[    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253

[    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
[    2.228678] leds_alix2: can't allocate I/O for GPIO


For reference dmesg of 2.6.31.3:

[    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253

[    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
[    2.399097] Registered led device: alix:1
[    2.411404] Registered led device: alix:2
[    2.423720] Registered led device: alix:3

Best regards,
Arnd

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Richard Purdie]

On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
> 
> relevant dmesg output of 2.6.33-rc3:
> 
> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> 
> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
> [    2.228678] leds_alix2: can't allocate I/O for GPIO
> 
> 
> For reference dmesg of 2.6.31.3:
> 
> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> 
> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
> [    2.399097] Registered led device: alix:1
> [    2.411404] Registered led device: alix:2
> [    2.423720] Registered led device: alix:3

Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
looks like the request_region() call is failing. Daniel, any idea why?

Cheers,

Richard

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Arnd Hannemann]

Richard Purdie schrieb:
> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>>
>> relevant dmesg output of 2.6.33-rc3:
>>
>> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>
>> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
>> [    2.228678] leds_alix2: can't allocate I/O for GPIO
>>
>>
>> For reference dmesg of 2.6.31.3:
>>
>> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>
>> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
>> [    2.399097] Registered led device: alix:1
>> [    2.411404] Registered led device: alix:2
>> [    2.423720] Registered led device: alix:3
> 
> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
> looks like the request_region() call is failing. Daniel, any idea why?

Some additional debug information:

elara:~# rdmsr 0x5140000C
f00100006100

/proc/ioports says:
6100-61ff : 0000:00:0f.0
  6100-61ff : cs5535_gpio

BTW: why is request_region() needed there after all?

Best regards,
Arnd

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Arnd Hannemann]

Arnd Hannemann schrieb:
> Richard Purdie schrieb:
>> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
>>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
>>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>>>
>>> relevant dmesg output of 2.6.33-rc3:
>>>
>>> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>
>>> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
>>> [    2.228678] leds_alix2: can't allocate I/O for GPIO
>>>
>>>
>>> For reference dmesg of 2.6.31.3:
>>>
>>> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>
>>> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
>>> [    2.399097] Registered led device: alix:1
>>> [    2.411404] Registered led device: alix:2
>>> [    2.423720] Registered led device: alix:3
>> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
>> looks like the request_region() call is failing. Daniel, any idea why?
> 
> Some additional debug information:
> 
> elara:~# rdmsr 0x5140000C
> f00100006100
> 
> /proc/ioports says:
> 6100-61ff : 0000:00:0f.0
>   6100-61ff : cs5535_gpio
> 
> BTW: why is request_region() needed there after all?

Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?

Best regards,
Arnd

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Daniel Mack]

On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> Arnd Hannemann schrieb:
> > Richard Purdie schrieb:
> >> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
> >>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
> >>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
> >>>
> >>> relevant dmesg output of 2.6.33-rc3:
> >>>
> >>> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> >>>
> >>> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
> >>> [    2.228678] leds_alix2: can't allocate I/O for GPIO
> >>>
> >>>
> >>> For reference dmesg of 2.6.31.3:
> >>>
> >>> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> >>>
> >>> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
> >>> [    2.399097] Registered led device: alix:1
> >>> [    2.411404] Registered led device: alix:2
> >>> [    2.423720] Registered led device: alix:3
> >> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
> >> looks like the request_region() call is failing. Daniel, any idea why?
> > 
> > Some additional debug information:
> > 
> > elara:~# rdmsr 0x5140000C
> > f00100006100
> > 
> > /proc/ioports says:
> > 6100-61ff : 0000:00:0f.0
> >   6100-61ff : cs5535_gpio
> > 
> > BTW: why is request_region() needed there after all?
> 
> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?

That is the problem indeed. The problem is that three of these GPIOs are
connected to LEDs, so if both drivers are enabled, they will both alter
the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
should use the GPIO interface and that's it?

Daniel

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Arnd Hannemann]

Hi,

Daniel Mack schrieb:
> On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
>> Arnd Hannemann schrieb:
>>> Richard Purdie schrieb:
>>>> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
>>>>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
>>>>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>>>>>
>>>>> relevant dmesg output of 2.6.33-rc3:
>>>>>
>>>>> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>>>
>>>>> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
>>>>> [    2.228678] leds_alix2: can't allocate I/O for GPIO
>>>>>
>>>>>
>>>>> For reference dmesg of 2.6.31.3:
>>>>>
>>>>> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>>>
>>>>> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
>>>>> [    2.399097] Registered led device: alix:1
>>>>> [    2.411404] Registered led device: alix:2
>>>>> [    2.423720] Registered led device: alix:3
>>>> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
>>>> looks like the request_region() call is failing. Daniel, any idea why?
>>> Some additional debug information:
>>>
>>> elara:~# rdmsr 0x5140000C
>>> f00100006100
>>>
>>> /proc/ioports says:
>>> 6100-61ff : 0000:00:0f.0
>>>   6100-61ff : cs5535_gpio
>>>
>>> BTW: why is request_region() needed there after all?
>> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> 
> That is the problem indeed. The problem is that three of these GPIOs are
> connected to LEDs, so if both drivers are enabled, they will both alter
> the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> should use the GPIO interface and that's it?

I'm not sure that this configuration needs to be supported at all,
so disallowing that both drivers are configured via Kconfig could be a simple solution.

If I understand correctly, for off-the-shelf ALIX2 boards, beside the LEDs,
there is only one other GPIO pin being usable (the "mode switch"), anyway.

Best regards,
Arnd

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Daniel Mack]

Hi,

On Thu, Jan 07, 2010 at 03:00:37PM +0100, Arnd Hannemann wrote:
> Daniel Mack schrieb:
> > On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> >> Arnd Hannemann schrieb:
> >>> Richard Purdie schrieb:
> >>>> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
> >>>>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
> >>>>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
> >>>>>
> >>>>> relevant dmesg output of 2.6.33-rc3:
> >>>>>
> >>>>> [    0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> >>>>>
> >>>>> [    2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
> >>>>> [    2.228678] leds_alix2: can't allocate I/O for GPIO
> >>>>>
> >>>>>
> >>>>> For reference dmesg of 2.6.31.3:
> >>>>>
> >>>>> [    0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
> >>>>>
> >>>>> [    2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
> >>>>> [    2.399097] Registered led device: alix:1
> >>>>> [    2.411404] Registered led device: alix:2
> >>>>> [    2.423720] Registered led device: alix:3
> >>>> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
> >>>> looks like the request_region() call is failing. Daniel, any idea why?
> >>> Some additional debug information:
> >>>
> >>> elara:~# rdmsr 0x5140000C
> >>> f00100006100
> >>>
> >>> /proc/ioports says:
> >>> 6100-61ff : 0000:00:0f.0
> >>>   6100-61ff : cs5535_gpio
> >>>
> >>> BTW: why is request_region() needed there after all?
> >> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> > 
> > That is the problem indeed. The problem is that three of these GPIOs are
> > connected to LEDs, so if both drivers are enabled, they will both alter
> > the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> > should use the GPIO interface and that's it?
> 
> I'm not sure that this configuration needs to be supported at all,
> so disallowing that both drivers are configured via Kconfig could be a simple solution.

True.

> If I understand correctly, for off-the-shelf ALIX2 boards, beside the LEDs,
> there is only one other GPIO pin being usable (the "mode switch"), anyway.

Yes. I also wrote a simple polled input device driver to support this
switch, but it was too much of a hack as it ended up being part of
the LED driver. The idea discussed back then was to clean up the code
so that the entire MSR lookup thing is only done once, and a platform
support for ALIX board then adds support for the LEDs via the leds-gpio
LED driver and for the button via gpio-buttons input driver. That would
be much nicer, but I haven't found the time yet to implement it.

Daniel

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Richard Purdie]

On Thu, 2010-01-07 at 15:00 +0100, Arnd Hannemann wrote:
> Daniel Mack schrieb:
> > On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> >> Arnd Hannemann schrieb:
> >> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> > 
> > That is the problem indeed. The problem is that three of these GPIOs are
> > connected to LEDs, so if both drivers are enabled, they will both alter
> > the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> > should use the GPIO interface and that's it?
> 
> I'm not sure that this configuration needs to be supported at all,
> so disallowing that both drivers are configured via Kconfig could be a simple solution.

Agreed, Kconfig dependencies for this until the code is improved look
like the best option. Does someone want to send me a patch?

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Daniel Mack]

On Thu, Jan 07, 2010 at 05:27:21PM +0000, Richard Purdie wrote:
> On Thu, 2010-01-07 at 15:00 +0100, Arnd Hannemann wrote:
> > Daniel Mack schrieb:
> > > On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> > >> Arnd Hannemann schrieb:
> > >> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> > > 
> > > That is the problem indeed. The problem is that three of these GPIOs are
> > > connected to LEDs, so if both drivers are enabled, they will both alter
> > > the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> > > should use the GPIO interface and that's it?
> > 
> > I'm not sure that this configuration needs to be supported at all,
> > so disallowing that both drivers are configured via Kconfig could be a simple solution.
> 
> Agreed, Kconfig dependencies for this until the code is improved look
> like the best option. Does someone want to send me a patch?

Does the one below look ok?

Thanks,
Daniel


>From ebb89d7d1908e85587f3e64bcea0dd77a92cc744 Mon Sep 17 00:00:00 2001
From: Daniel Mack <daniel@caiaq.de>
Date: Fri, 8 Jan 2010 02:22:10 +0800
Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335

The ALIX2 LED driver and the CS5535 GPIO driver share the same I/O
range which causes a conflict if they're both enabled. Fix this for now
by adding a Kconfig dependency. While at it, also drop the EXPERIMENTAL
flag, as the code has been around for awhile already.

Note that this is a hack. At some point, a real platform support for
this board should be added which handles the LEDs via the leds-gpio
driver.

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
 drivers/leds/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8a0e1ec..7f292ae 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -72,7 +72,7 @@ config LEDS_WRAP
 
 config LEDS_ALIX2
 	tristate "LED Support for ALIX.2 and ALIX.3 series"
-	depends on LEDS_CLASS && X86 && EXPERIMENTAL
+	depends on LEDS_CLASS && X86 && !GPIO_CS5535
 	help
 	  This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
 	  You have to set leds-alix2.force=1 for boards with Award BIOS.
-- 
1.6.3.3

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Arnd Hannemann]

Daniel Mack schrieb:
> On Thu, Jan 07, 2010 at 05:27:21PM +0000, Richard Purdie wrote:
>> On Thu, 2010-01-07 at 15:00 +0100, Arnd Hannemann wrote:
>>> Daniel Mack schrieb:
>>>> On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
>>>>> Arnd Hannemann schrieb:
>>>>> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
>>>> That is the problem indeed. The problem is that three of these GPIOs are
>>>> connected to LEDs, so if both drivers are enabled, they will both alter
>>>> the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
>>>> should use the GPIO interface and that's it?
>>> I'm not sure that this configuration needs to be supported at all,
>>> so disallowing that both drivers are configured via Kconfig could be a simple solution.
>> Agreed, Kconfig dependencies for this until the code is improved look
>> like the best option. Does someone want to send me a patch?
> 
> Does the one below look ok?
> 
> Thanks,
> Daniel
> 
> 
> From ebb89d7d1908e85587f3e64bcea0dd77a92cc744 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <daniel@caiaq.de>
> Date: Fri, 8 Jan 2010 02:22:10 +0800
> Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
> 
> The ALIX2 LED driver and the CS5535 GPIO driver share the same I/O
> range which causes a conflict if they're both enabled. Fix this for now
> by adding a Kconfig dependency. While at it, also drop the EXPERIMENTAL
> flag, as the code has been around for awhile already.
> 
> Note that this is a hack. At some point, a real platform support for
> this board should be added which handles the LEDs via the leds-gpio
> driver.
> 
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
>  drivers/leds/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 8a0e1ec..7f292ae 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -72,7 +72,7 @@ config LEDS_WRAP
>  
>  config LEDS_ALIX2
>  	tristate "LED Support for ALIX.2 and ALIX.3 series"
> -	depends on LEDS_CLASS && X86 && EXPERIMENTAL
> +	depends on LEDS_CLASS && X86 && !GPIO_CS5535

You should add && !CS5535_GPIO, too. In fact CS5535_GPIO
was the one that I had issues with. Though, I wonder why
there are multiple drivers... Buts thats another issue.

>  	help
>  	  This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
>  	  You have to set leds-alix2.force=1 for boards with Award BIOS.

Best regards,
Arnd

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Daniel Mack]

On Fri, Jan 08, 2010 at 09:32:33AM +0100, Arnd Hannemann wrote:
> Daniel Mack schrieb:

[...]

> > From ebb89d7d1908e85587f3e64bcea0dd77a92cc744 Mon Sep 17 00:00:00 2001
> > From: Daniel Mack <daniel@caiaq.de>
> > Date: Fri, 8 Jan 2010 02:22:10 +0800
> > Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
> > 
> > The ALIX2 LED driver and the CS5535 GPIO driver share the same I/O
> > range which causes a conflict if they're both enabled. Fix this for now
> > by adding a Kconfig dependency. While at it, also drop the EXPERIMENTAL
> > flag, as the code has been around for awhile already.
> > 
> > Note that this is a hack. At some point, a real platform support for
> > this board should be added which handles the LEDs via the leds-gpio
> > driver.
> > 
> > Signed-off-by: Daniel Mack <daniel@caiaq.de>
> > Cc: Richard Purdie <rpurdie@rpsys.net>
> > Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> > ---
> >  drivers/leds/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 8a0e1ec..7f292ae 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -72,7 +72,7 @@ config LEDS_WRAP
> >  
> >  config LEDS_ALIX2
> >  	tristate "LED Support for ALIX.2 and ALIX.3 series"
> > -	depends on LEDS_CLASS && X86 && EXPERIMENTAL
> > +	depends on LEDS_CLASS && X86 && !GPIO_CS5535
> 
> You should add && !CS5535_GPIO, too. In fact CS5535_GPIO
> was the one that I had issues with. Though, I wonder why
> there are multiple drivers... Buts thats another issue.

Ah, right, thanks for noticing. New patch below.

Daniel


>From 0ce35578c6705dd1c44d076529df6dba889b7b76 Mon Sep 17 00:00:00 2001
From: Daniel Mack <daniel@caiaq.de>
Date: Fri, 8 Jan 2010 02:22:10 +0800
Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335

The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O
range which causes a conflict if they're both enabled. Fix this for now
by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL
flag, as the code has been around for awhile already.

Note that this is a hack. At some point, a real platform support for
this board should be added which handles the LEDs via the leds-gpio
driver.

Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
 drivers/leds/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8a0e1ec..fef1cf4 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -72,7 +72,7 @@ config LEDS_WRAP
 
 config LEDS_ALIX2
 	tristate "LED Support for ALIX.2 and ALIX.3 series"
-	depends on LEDS_CLASS && X86 && EXPERIMENTAL
+	depends on LEDS_CLASS && X86 && !GPIO_CS5535 && !CS5535_GPIO
 	help
 	  This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
 	  You have to set leds-alix2.force=1 for boards with Award BIOS.
-- 
1.6.3.3

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Daniel Mack]

ping?

On Sun, Jan 10, 2010 at 01:27:54PM +0100, Daniel Mack wrote:
> On Fri, Jan 08, 2010 at 09:32:33AM +0100, Arnd Hannemann wrote:
> > Daniel Mack schrieb:
> 
> [...]
> 
> > > From ebb89d7d1908e85587f3e64bcea0dd77a92cc744 Mon Sep 17 00:00:00 2001
> > > From: Daniel Mack <daniel@caiaq.de>
> > > Date: Fri, 8 Jan 2010 02:22:10 +0800
> > > Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
> > > 
> > > The ALIX2 LED driver and the CS5535 GPIO driver share the same I/O
> > > range which causes a conflict if they're both enabled. Fix this for now
> > > by adding a Kconfig dependency. While at it, also drop the EXPERIMENTAL
> > > flag, as the code has been around for awhile already.
> > > 
> > > Note that this is a hack. At some point, a real platform support for
> > > this board should be added which handles the LEDs via the leds-gpio
> > > driver.
> > > 
> > > Signed-off-by: Daniel Mack <daniel@caiaq.de>
> > > Cc: Richard Purdie <rpurdie@rpsys.net>
> > > Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> > > ---
> > >  drivers/leds/Kconfig |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > > index 8a0e1ec..7f292ae 100644
> > > --- a/drivers/leds/Kconfig
> > > +++ b/drivers/leds/Kconfig
> > > @@ -72,7 +72,7 @@ config LEDS_WRAP
> > >  
> > >  config LEDS_ALIX2
> > >  	tristate "LED Support for ALIX.2 and ALIX.3 series"
> > > -	depends on LEDS_CLASS && X86 && EXPERIMENTAL
> > > +	depends on LEDS_CLASS && X86 && !GPIO_CS5535
> > 
> > You should add && !CS5535_GPIO, too. In fact CS5535_GPIO
> > was the one that I had issues with. Though, I wonder why
> > there are multiple drivers... Buts thats another issue.
> 
> Ah, right, thanks for noticing. New patch below.
> 
> Daniel
> 
> 
> From 0ce35578c6705dd1c44d076529df6dba889b7b76 Mon Sep 17 00:00:00 2001
> From: Daniel Mack <daniel@caiaq.de>
> Date: Fri, 8 Jan 2010 02:22:10 +0800
> Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
> 
> The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O
> range which causes a conflict if they're both enabled. Fix this for now
> by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL
> flag, as the code has been around for awhile already.
> 
> Note that this is a hack. At some point, a real platform support for
> this board should be added which handles the LEDs via the leds-gpio
> driver.
> 
> Signed-off-by: Daniel Mack <daniel@caiaq.de>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
>  drivers/leds/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 8a0e1ec..fef1cf4 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -72,7 +72,7 @@ config LEDS_WRAP
>  
>  config LEDS_ALIX2
>  	tristate "LED Support for ALIX.2 and ALIX.3 series"
> -	depends on LEDS_CLASS && X86 && EXPERIMENTAL
> +	depends on LEDS_CLASS && X86 && !GPIO_CS5535 && !CS5535_GPIO
>  	help
>  	  This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
>  	  You have to set leds-alix2.force=1 for boards with Award BIOS.
> -- 
> 1.6.3.3
> 

Re: 2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

[Richard Purdie]

On Sun, 2010-01-10 at 13:27 +0100, Daniel Mack wrote:
> Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
> 
> The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O
> range which causes a conflict if they're both enabled. Fix this for now
> by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL
> flag, as the code has been around for awhile already.
> 
> Note that this is a hack. At some point, a real platform support for
> this board should be added which handles the LEDs via the leds-gpio
> driver.

Queued in the LED tree, thanks. I'll push this one to Linus shortly for
2.6.33.

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre