Hi!

> > > > Player LEDs are commonly found on game controllers from Nintendo and Sony
> > > > to indicate a player ID across a number of LEDs. For example, "Player 2"
> > > > might be indicated as "-x--" on a device with 4 LEDs where "x" means on.
> > > >
> > > > This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate
> > > > player LEDs from the kernel. Until now there was no good standard, which
> > > > resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and
> > > > other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx.
> > > >
> > > > Note: management of Player IDs is left to user space, though a kernel
> > > > driver may pick a default value.
> > > >
> > > > Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
> > > > ---
> > > >  Documentation/leds/well-known-leds.txt | 14 ++++++++++++++
> > > >  include/dt-bindings/leds/common.h      |  7 +++++++
> > > >  2 files changed, 21 insertions(+)
> > >
> > > Pavel, could you please eventually Ack this, so that I can take it
> > > together with the rest?
> >
> > I'm willing to take Documentation/leds/well-known-leds.txt part
> > through LED tree.
> >
> > I don't like the common.h change; either avoid the define or put it
> > into your local header.
> 
> If the LED_FUNCTION_PLAYER* defines don't belong in common with the
> other LED_FUNCTION* ones, where should it go? The hid-nintendo driver
> intends to use the same defines, so defining it local to each driver
> isn't right. Not sure if there is a great place in the input system
> either (you would then have to move scrolllock and all those other LED
> definitions too.)

Ok, so let's put it in the common place. I'll take this patch through
LED tree if you resubmit it. You still may want to use local defines
so you can apply the other patches without waiting.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek