From patchwork Wed Jul 22 21:47:40 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Machek X-Patchwork-Id: 6846871 Return-Path: X-Original-To: patchwork-linux-input@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1D5F29F1D4 for ; Wed, 22 Jul 2015 21:47:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 337F720562 for ; Wed, 22 Jul 2015 21:47:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F91D20571 for ; Wed, 22 Jul 2015 21:47:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753309AbbGVVro (ORCPT ); Wed, 22 Jul 2015 17:47:44 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:46196 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753025AbbGVVrn (ORCPT ); Wed, 22 Jul 2015 17:47:43 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 9D54882074; Wed, 22 Jul 2015 23:47:41 +0200 (CEST) Date: Wed, 22 Jul 2015 23:47:40 +0200 From: Pavel Machek To: Jiri Kosina Cc: Vlastimil Babka , Dmitry Torokhov , 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: <20150722214739.GA15790@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> <55AFAB9B.2090101@suse.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 > 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. 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",