[v2,1/3] Input: export LEDs as class devices in sysfs

Commit Message

Pavel Machek July 22, 2015, 9:47 p.m. UTC

On Wed 2015-07-22 21:49:06, Jiri Kosina wrote:
> On Wed, 22 Jul 2015, Vlastimil Babka wrote:
> 
> > [  101.805120] usb 3-4: new low-speed USB device number 3 using xhci_hcd
> > [  101.979584] usb 3-4: New USB device found, idVendor=046d, idProduct=c50e
> > [  101.979589] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> > [  101.979592] usb 3-4: Product: USB Receiver
> > [  101.979594] usb 3-4: Manufacturer: Logitech
> > [  101.979805] usb 3-4: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
> > [  101.989010] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989014] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989017] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989019] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989021] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989023] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989025] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989027] hid-generic 0003:046D:C50E.0003: Mapped LED usage 4b as LED 8
> > [  101.989091] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/0003:046D:C50E.0003/input/input14
> > [  102.039320] ------------[ cut here ]------------
> > [  102.039329] WARNING: CPU: 6 PID: 168 at ../drivers/input/input-leds.c:115 input_leds_connect+0x22b/0x260()
> > 
> > (5 WARNINGs as before)
> > 
> > [  102.040729] hid-generic 0003:046D:C50E.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-4/input0
> 
> Alright, I think it's pretty obvious what's happening. Vlastimil, am I 
> right that the patch below fixes the issue?
> 
> I am however not sure whether input_leds_connect() is not too unkind to 
> unnamed LEDs and shouldn't be more tolerant to those in the long term.


Maybe.

> From: Jiri Kosina <[e-mail]>
> Subject: [PATCH] Input: leds: don't attempt to deregister unnamed LEDs
> 
> input_leds_connect() is skipping registration of LEDs for which
> there is no symbolic name in input_led_info[].

Yes, and rather than testing for "no name" special case at two places,
what about simply giving up when we see such error?

S-o-b: me.

Comments

Jiri Kosina July 22, 2015, 9:50 p.m. UTC | #1

On Wed, 22 Jul 2015, Pavel Machek wrote:

> > I am however not sure whether input_leds_connect() is not too unkind to 
> > unnamed LEDs and shouldn't be more tolerant to those in the long term.
> 
> Maybe.
> 
> > From: Jiri Kosina <[e-mail]>
> > Subject: [PATCH] Input: leds: don't attempt to deregister unnamed LEDs
> > 
> > input_leds_connect() is skipping registration of LEDs for which
> > there is no symbolic name in input_led_info[].
> 
> Yes, and rather than testing for "no name" special case at two places,
> what about simply giving up when we see such error?

Well, that's quite the oposite of the "be more tolerant" aproach proposed 
above :)

I don't see a reason why the sole fact that the device has at least one 
LED that kernel can't handle properly should mean that neither of the 
other LEDs will work.

Patch

diff --git a/drivers/input/input-leds.c b/drivers/input/input-leds.c
index 074a65e..5f300e6 100644
--- a/drivers/input/input-leds.c
+++ b/drivers/input/input-leds.c
@@ -112,7 +112,11 @@  static int input_leds_connect(struct input_handler *handler,
 		led->handle = &leds->handle;
 		led->code = led_code;
 
-		if (WARN_ON(!input_led_info[led_code].name))
+		if (!input_led_info[led_code].name) {
+			printk(KERN_ERR, "LED with no name\n");
+			error = -EINVAL;
+			goto err_unregister_leds;
+		}
 			continue;
 
 		led->cdev.name = kasprintf(GFP_KERNEL, "%s::%s",