Hi,
Unfortunately the following commit:
commit 35ff8554d12ecc80a46ea0d9bce34fe28733ff38
Author: ?ric Piel <[email protected]>
Date: Sat Nov 22 19:29:29 2008 +0100
sdhci: activate led support also when module
CONFIG_LEDS_CLASS is defined only if led-class is built-in, otherwise
when it is a module the option is called CONFIG_LEDS_CLASS_MODULE. Led
support should also be activated in this case.
Signed-off-by: Eric Piel <[email protected]>
Signed-off-by: Pierre Ossman <[email protected]>
causes hald to segfault at startup (not always, but sufficiently often for
bisection) on my Toshiba Portege R500 w/ x86_64 kernel/userland.
While it doesn't revert cleanly, I have applied the appended patch (which is
a revert of the commit above) and hald doesn't segfault any more here.
Thanks,
Rafael
---
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 6b2d1f9..8ce6250 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -154,7 +154,7 @@ static void sdhci_deactivate_led(struct sdhci_host *host)
writeb(ctrl, host->ioaddr + SDHCI_HOST_CONTROL);
}
-#ifdef SDHCI_USE_LEDS_CLASS
+#ifdef CONFIG_LEDS_CLASS
static void sdhci_led_control(struct led_classdev *led,
enum led_brightness brightness)
{
@@ -999,7 +999,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
WARN_ON(host->mrq != NULL);
-#ifndef SDHCI_USE_LEDS_CLASS
+#ifndef CONFIG_LEDS_CLASS
sdhci_activate_led(host);
#endif
@@ -1206,7 +1206,7 @@ static void sdhci_tasklet_finish(unsigned long param)
host->cmd = NULL;
host->data = NULL;
-#ifndef SDHCI_USE_LEDS_CLASS
+#ifndef CONFIG_LEDS_CLASS
sdhci_deactivate_led(host);
#endif
@@ -1722,7 +1722,7 @@ int sdhci_add_host(struct sdhci_host *host)
sdhci_dumpregs(host);
#endif
-#ifdef SDHCI_USE_LEDS_CLASS
+#ifdef CONFIG_LEDS_CLASS
host->led.name = mmc_hostname(mmc);
host->led.brightness = LED_OFF;
host->led.default_trigger = mmc_hostname(mmc);
@@ -1744,7 +1744,7 @@ int sdhci_add_host(struct sdhci_host *host)
return 0;
-#ifdef SDHCI_USE_LEDS_CLASS
+#ifdef CONFIG_LEDS_CLASS
reset:
sdhci_reset(host, SDHCI_RESET_ALL);
free_irq(host->irq, host);
@@ -1780,7 +1780,7 @@ void sdhci_remove_host(struct sdhci_host *host, int dead)
mmc_remove_host(host->mmc);
-#ifdef SDHCI_USE_LEDS_CLASS
+#ifdef CONFIG_LEDS_CLASS
led_classdev_unregister(&host->led);
#endif
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 3efba23..31f4b15 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -220,7 +220,7 @@ struct sdhci_host {
struct mmc_host *mmc; /* MMC structure */
u64 dma_mask; /* custom DMA mask */
-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#ifdef CONFIG_LEDS_CLASS
struct led_classdev led; /* LED control */
#endif
On Thu, 8 Jan 2009 08:27:02 +0100
"Rafael J. Wysocki" <[email protected]> wrote:
> Hi,
>
> Unfortunately the following commit:
>
> commit 35ff8554d12ecc80a46ea0d9bce34fe28733ff38
> Author: Éric Piel <[email protected]>
> Date: Sat Nov 22 19:29:29 2008 +0100
>
> sdhci: activate led support also when module
>
> CONFIG_LEDS_CLASS is defined only if led-class is built-in, otherwise
> when it is a module the option is called CONFIG_LEDS_CLASS_MODULE. Led
> support should also be activated in this case.
>
> Signed-off-by: Eric Piel <[email protected]>
> Signed-off-by: Pierre Ossman <[email protected]>
>
> causes hald to segfault at startup (not always, but sufficiently often for
> bisection) on my Toshiba Portege R500 w/ x86_64 kernel/userland.
>
I have trouble seeing a user space application crashing as a kernel
bug. Do you have a backtrace or strace of hald to see exactly where it
crashes?
> While it doesn't revert cleanly, I have applied the appended patch (which is
> a revert of the commit above) and hald doesn't segfault any more here.
>
Is CONFIG_LEDS_CLASS defined in your config, or are you essentially
turning of the LED functionality?
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Thursday 08 January 2009, Pierre Ossman wrote:
> On Thu, 8 Jan 2009 08:27:02 +0100
> "Rafael J. Wysocki" <[email protected]> wrote:
>
> > Hi,
> >
> > Unfortunately the following commit:
> >
> > commit 35ff8554d12ecc80a46ea0d9bce34fe28733ff38
> > Author: ?ric Piel <[email protected]>
> > Date: Sat Nov 22 19:29:29 2008 +0100
> >
> > sdhci: activate led support also when module
> >
> > CONFIG_LEDS_CLASS is defined only if led-class is built-in, otherwise
> > when it is a module the option is called CONFIG_LEDS_CLASS_MODULE. Led
> > support should also be activated in this case.
> >
> > Signed-off-by: Eric Piel <[email protected]>
> > Signed-off-by: Pierre Ossman <[email protected]>
> >
> > causes hald to segfault at startup (not always, but sufficiently often for
> > bisection) on my Toshiba Portege R500 w/ x86_64 kernel/userland.
> >
>
> I have trouble seeing a user space application crashing as a kernel
> bug. Do you have a backtrace or strace of hald to see exactly where it
> crashes?
No, I don't. I'll try to get one later.
> > While it doesn't revert cleanly, I have applied the appended patch (which is
> > a revert of the commit above) and hald doesn't segfault any more here.
> >
>
> Is CONFIG_LEDS_CLASS defined in your config, or are you essentially
> turning of the LED functionality?
I have CONFIG_LEDS_CLASS=m (so I guess the patch just makes the led support
in sdhci active).
Thanks,
Rafael