Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933659AbbGUVIy (ORCPT ); Tue, 21 Jul 2015 17:08:54 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45214 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932776AbbGUVIx (ORCPT ); Tue, 21 Jul 2015 17:08:53 -0400 Date: Tue, 21 Jul 2015 23:08:50 +0200 From: Pavel Machek To: Dmitry Torokhov Cc: Vlastimil Babka , Samuel Thibault , Pali =?iso-8859-1?Q?Roh=E1r?= , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, rpurdie@rpsys.net, Greg Kroah-Hartman Subject: Re: [PATCH v2 1/3] Input: export LEDs as class devices in sysfs Message-ID: <20150721210850.GA13242@amd> References: <1433799790-31873-1-git-send-email-dmitry.torokhov@gmail.com> <1433799790-31873-2-git-send-email-dmitry.torokhov@gmail.com> <20150609174211.GH6338@dtor-ws> <55AE299F.3010002@suse.cz> <20150721170133.GA39076@dtor-ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150721170133.GA39076@dtor-ws> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3609 Lines: 70 On Tue 2015-07-21 10:01:33, Dmitry Torokhov wrote: > 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 > > > > > > 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 > > > Signed-off-by: Dmitry Torokhov > > > --- > > > > > + 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] [] dump_stack+0x4c/0x6e > > [ 2.782474] [] warn_slowpath_common+0x86/0xc0 > > [ 2.782476] [] warn_slowpath_null+0x1a/0x20 > > [ 2.782478] [] input_leds_connect+0x22b/0x260 > > [ 2.782480] [] input_attach_handler+0x1a2/0x1f0 > > [ 2.782483] [] input_register_device+0x440/0x4f0 > > [ 2.782486] [] hidinput_connect+0x334/0x5d0 > > [ 2.782488] [] 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 we get rid of WARN_ON, then? It is nasty to flood logs, and people are likely to flood our inboxes, soon. printk(KERN_ERR) should be adequate... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/