[origin tree build failure] [PATCH] input: Fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry

[origin tree build failure] [PATCH] input: Fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry

[Ingo Molnar]

( ob-sidenote: Andrew, i did not find the patch for commit 16af5bb on 
  lkml and it's now upstream. It would be highly useful if you Cc:-ed 
  lkml with submitted patches like all maintainers do, so that patterns 
  can be grepped for and discussions can be continued quickly instead of 
  created anew. It would also significantly increase the S/N ratio of 
  lkml. Thanks! )

>From 16af5bbc3be6cd9d0861b8ec381df3fe835977c3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 23 Sep 2009 09:09:32 +0200
Subject: [PATCH] input: Fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry

-tip testing found this build failure:

  drivers/built-in.o: In function `apanel_remove':
  apanel.c:(.text+0x56e852): undefined reference to `led_classdev_unregister'
  drivers/built-in.o: In function `apanel_probe':
  apanel.c:(.text+0x56eae3): undefined reference to `led_classdev_register'
  drivers/built-in.o: In function `acpi_fujitsu_hotkey_add':
  fujitsu-laptop.c:(.text+0x5d7647): undefined reference to `led_classdev_register'
  fujitsu-laptop.c:(.text+0x5d76b5): undefined reference to `led_classdev_register'
  drivers/built-in.o: In function `wbcir_probe':
  winbond-cir.c:(.devinit.text+0x5f375): undefined reference to `led_classdev_register'
  winbond-cir.c:(.devinit.text+0x5f663): undefined reference to `led_classdev_unregister'
  drivers/built-in.o: In function `wbcir_remove':
  winbond-cir.c:(.devexit.text+0x7f23): undefined reference to `led_classdev_unregister'
  drivers/built-in.o: In function `fujitsu_cleanup':
  fujitsu-laptop.c:(.exit.text+0xbe37): undefined reference to `led_classdev_unregister'
  fujitsu-laptop.c:(.exit.text+0xbe53): undefined reference to `led_classdev_unregister'

It happens because the new INPUT_WINBOND_CIR driver relies
on new-leds infrastructure - but does not select it in
drivers/input/misc/Kconfig. But it selects LEDS_CLASS,
which confuses a number of other drivers into thinking
that all the leds infrastructure is in place.

Fix this by selecting NEW_LEDS as well, like similar drivers do.

Eventually, this whole leds infrastructure complexity should be
cleaned up, it's been going on for years.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/input/misc/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 76d6751..02f4f8f 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -225,6 +225,7 @@ config INPUT_SGI_BTNS
 config INPUT_WINBOND_CIR
 	tristate "Winbond IR remote control"
 	depends on X86 && PNP
+	select NEW_LEDS
 	select LEDS_CLASS
 	select BITREVERSE
 	help

Re: [origin tree build failure] [PATCH] input: Fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry

[Andrew Morton]

On Wed, 23 Sep 2009 09:24:44 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> ( ob-sidenote: Andrew, i did not find the patch for commit 16af5bb on 
>   lkml and it's now upstream. It would be highly useful if you Cc:-ed 
>   lkml with submitted patches like all maintainers do, so that patterns 
>   can be grepped for and discussions can be continued quickly instead of 
>   created anew. It would also significantly increase the S/N ratio of 
>   lkml. Thanks! )

I did that a couple of times a few years back and vger had a heart
attack.  I could cc the lower-subscriber-count mm-commits but that
wouldn't help much.

16af5bb doesn't exist btw - you want e258b80e691f1f3ae83a60aa80eaf7322bd55ec4.

Re: [origin tree build failure] [PATCH] input: Fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 23 Sep 2009 09:24:44 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > ( ob-sidenote: Andrew, i did not find the patch for commit 16af5bb on 
> >   lkml and it's now upstream. It would be highly useful if you Cc:-ed 
> >   lkml with submitted patches like all maintainers do, so that patterns 
> >   can be grepped for and discussions can be continued quickly instead of 
> >   created anew. It would also significantly increase the S/N ratio of 
> >   lkml. Thanks! )
> 
> I did that a couple of times a few years back and vger had a heart 
> attack.  I could cc the lower-subscriber-count mm-commits but that 
> wouldn't help much.

Mass mailings of this order of magnitude are more common now and vger 
ought to cope. It would be sad to skip the useful stuff while keeping 
all the noise ;-)

At least as far as i'm concerned i grep for a commit's title and reply 
to the last relevant mail in the thread that comes up on lkml. That kind 
of activity would be sufficiently helped by a summary mail Cc:-ed to 
lkml. (And there's rumors that there's a wonderful new tool for that, 
written by a git - so i heard.)

Alternatively (or in addition to that) the mm commits list could Cc: 
over to lkml.

( It might even use LKML-Reference tag for that purpose - that way 
  patches which are queued up (or updated) in -mm will show up on lkml 
  gradually and in relevant threads. Highly useful in practice - not 
  only does it make the flow of patches more transparent on lkml, it 
  also links the commit back to the discussion and allows others to 
  chime in later in the discussion (even if they were not Cc:-ed and are 
  hence outside the usual scope of mm-commits). Dunno whether you 
  consider it worth it to update the mm-commits scripts to that end. 
  Since you pick patches from emails it seems a perfect match to me. 
  YMMV. )

And if that is done then git-commits-head@vger.kernel.org could Cc: back 
to lkml if a LKML-Reference tag is present, and the 'hits upstream' 
notification would thus thread back to the original discussion as well.

All in the name of eternal laziness.

> 16af5bb doesn't exist btw - you want e258b80e691f1f3ae83a60aa80eaf7322bd55ec4.

Yeah, you are right, i meant e258b80e (correctly mentioned in the 
changelog).

	Ingo