On Tue, Jul 21, 2015 at 01:14:39PM +0200, Vlastimil Babka wrote:
> On 06/09/2015 07:42 PM, Dmitry Torokhov wrote:
> > From: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> >
> > This change creates a new input handler called "leds" that exports LEDs on input
> > devices as standard LED class devices in sysfs and allows controlling their
> > ptate via sysfs or via any of the standard LED triggers. This allows to
> > re-purpose and reassign LDEs on the keyboards to represent states other
> > than the standard keyboard states (CapsLock, NumLock, etc).
> >
> > The old API of controlling input LEDs by writing into /dev/input/eventX
> > devices is still present and will take precedence over acessing via LEDs
> > subsystem (i.e. it may override state set by a trigger). If input device is
> > "grabbed" then requests coming through LED subsystem will be ignored.
> >
> > Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
> > ---
>
> > + led_no = 0;
> > + for_each_set_bit(led_code, dev->ledbit, LED_CNT) {
> > + struct input_led *led = &leds->leds[led_no];
> > +
> > + led->handle = &leds->handle;
> > + led->code = led_code;
> > +
> > + if (WARN_ON(!input_led_info[led_code].name))
> > + continue;
> > +
>
> Hi,
> I get several warnings on booting 4.2-rc2 here. Should I be worried?
>
> [ 2.782432] ------------[ cut here ]------------
> [ 2.782440] WARNING: CPU: 2 PID: 356 at ../drivers/input/input-leds.c:115 input_leds_connect+0x22b/0x260()
> [ 2.782441] Modules linked in: btrfs xor raid6_pq crc32c_intel radeon i2c_algo_bit sr_mod cdrom drm_kms_helper ttm e1000e drm xhci_pci ptp pps_core xhci_hcd sg
> [ 2.782453] CPU: 2 PID: 356 Comm: kworker/2:2 Not tainted 4.2.0-rc2-1.g288d56b-desktop #1
> [ 2.782454] Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A13 03/27/2013
> [ 2.782458] Workqueue: usb_hub_wq hub_event
> [ 2.782459] ffffffff81a917b7 ffff880213ecf298 ffffffff8169f19d 0000000000000007
> [ 2.782462] 0000000000000000 ffff880213ecf2d8 ffffffff810674f6 ffff880213ecf2f8
> [ 2.782463] ffff8802132fb000 0000000000000003 000000000000000b ffff8800369ff000
> [ 2.782465] Call Trace:
> [ 2.782470] [<ffffffff8169f19d>] dump_stack+0x4c/0x6e
> [ 2.782474] [<ffffffff810674f6>] warn_slowpath_common+0x86/0xc0
> [ 2.782476] [<ffffffff810675ea>] warn_slowpath_null+0x1a/0x20
> [ 2.782478] [<ffffffff8152ccdb>] input_leds_connect+0x22b/0x260
> [ 2.782480] [<ffffffff815281b2>] input_attach_handler+0x1a2/0x1f0
> [ 2.782483] [<ffffffff81528640>] input_register_device+0x440/0x4f0
> [ 2.782486] [<ffffffff8156e494>] hidinput_connect+0x334/0x5d0
> [ 2.782488] [<ffffffff815683d4>] hid_connect+0x324/0x400
No, this is benign. I guess your keyboard has more LEDs than input
system has defined or several usages refer to the same LED.
Can you try debug patch below and post the messages?
--
Dmitry
---
drivers/hid/hid-input.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 14aebe4..8690a84 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -657,6 +657,7 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
default: goto ignore;
}
+ hid_info(device, "Mapped LED usage %02x as LED %d\n", usage->hid & 0xffff, usage->code);
break;
case HID_UP_DIGITIZER:
@@ -971,6 +972,8 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
if (field->report_size == 1) {
if (field->report->type == HID_OUTPUT_REPORT) {
map_led(LED_MISC);
+ hid_info(device, "Mapped output report usage %08x as MISC LED %d\n",
+ usage->hid, usage->code);
break;
}
map_key(BTN_MISC);
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
