Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1534809yba; Sat, 6 Apr 2019 15:21:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2R/s805QayBKwbpTP7LVwEduEC/8txpxoep9ApIt/U8s7u6pyUrkKM8yAKvgRmnD8OnrL X-Received: by 2002:aa7:8c86:: with SMTP id p6mr21283911pfd.37.1554589261600; Sat, 06 Apr 2019 15:21:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554589261; cv=none; d=google.com; s=arc-20160816; b=q+HMek+SV6ovwEG7Ne/bseS6QiOrxXRLLsxSZ/mMG4MdwCOTBm5RB7Luj/+v5lRaOK 1tmj690pT1v9oWMCWpmwruMZM4//mhC+puB6jFLtIaSdwgK5F5B9wnTi5CBbOH+qdQfR JI/PXHRikUVfYb5MheBiKwnrWi9QmoXKkM1X6BcnAPrF75BbiL9V4YQRFrZVAbCJCBG2 siI10l2ZtXBkHYoHjirjzkewepf3wBf2bXvQSOIHeCE2swXwZeNlzC1DV+HS3BfrXREY SrTBg7syxCf3N7I6ea8uP2YCAUy5o18ntz4c6ayC3kifU0DAH0QBkGbsd1Z/OeR6dG90 VCmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=JGrBmyt6pGOJv+/zt/mUDbMoYBMnRthg+oxEwnbQANE=; b=mCTmCY4ESeSge1BA4g3byvvSdXgKUqJGSEfz90JXdKZvKCC1Q2uu9uUIkGmeSR9xxs 3HXtaBeb25MVNhLvHwZGSH8iifsPdEiROnQPWqx6sNdEnYEn5L1FYbgVnkmsV8+ELU97 M1TXPEvL7IYLQgyTIPZ3CutApmPddzE7m/9ksDme1EW7VbK/lnzy0zTZlkfXeYvHF/pR Lm/7QACxH/WLGpe5SCb17cnUgj5D7/MPeiyGDzAolQJvOhu6QE09x8mwJ6bTf87OsqiG mEkaU5Zm22DsmeNGn1ufhh0fC1qyAg21L2UjrGKDLe6mmCQDRozvmFgCb7EQ9SxunTkU AsnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x17si22191939pgj.195.2019.04.06.15.20.46; Sat, 06 Apr 2019 15:21:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726565AbfDFWRz (ORCPT + 99 others); Sat, 6 Apr 2019 18:17:55 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:37110 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726151AbfDFWRz (ORCPT ); Sat, 6 Apr 2019 18:17:55 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id F415F80378; Sun, 7 Apr 2019 00:17:44 +0200 (CEST) Date: Sun, 7 Apr 2019 00:17:56 +0200 From: Pavel Machek To: Jacek Anaszewski Cc: Enric Balletbo i Serra , Guenter Roeck , Dmitry Torokhov , Nick Crews , Benson Leung , linux-leds@vger.kernel.org, Alexandre Belloni , Alessandro Zummo , linux-rtc@vger.kernel.org, linux-kernel , Duncan Laurie , Simon Glass Subject: Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name Message-ID: <20190406221756.GA4472@amd> References: <20190404202042.GF29984@amd> <20190404204207.GH29984@amd> <20190404220509.GA14690@amd> <469dfb68-a7ab-668d-15cb-9e021c0d3f0c@gmail.com> <20190406095346.GB7546@amd> <1b45b4e8-18b6-62d5-7d42-0feed57c2c73@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <1b45b4e8-18b6-62d5-7d42-0feed57c2c73@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >I am not sure about existing driver. Important thing for me is that > >new drivers use consistent naming. > > > >>In cases like above: > >> > >> keyboardist::kbd_backlight > >> tclnumpad::kbd_backlight > >> > >>we could do with the following: > >> > >> :kbd-backlight > >> :numpad-backlight > >> > >>I used hyphens instead of underscores since we will have this convention > >>in the LED_FUNCTION names, which is more common for Device Tree, and > >>some of existing LED triggers. > > > >Existing userspace already searches for *:kbd_backlight", AFAICT, so > >we probably want to keep the "_". >=20 > OK, but it should be an exception but not a rule. > This "kbd-*" naming is used in input and tty subsystems which register > keyboard triggers with this style: >=20 > ~/kernel$ git grep ".*[\":]kbd-" -- "*.c" > drivers/input/input-leds.c: [LED_NUML] =3D { "numlock", > VT_TRIGGER("kbd-numlock") }, > "kbd_" naming is used only in case of backlight LEDs: >=20 > ~/kernel$ git grep ".*[\":]kbd_" -- "*.c" > drivers/hid/hid-asus.c: drvdata->kbd_backlight->cdev.name =3D > "asus::kbd_backlight"; Yes, but userland already knows about kbd_backlight, so we really can not change this. > With LEDs in platform drivers is that problem that we have the name > compiled into the kernel. Maybe to make it more flexible we could > use kernel config to choose between new "kbd-" and legacy "kbd_" > naming. No, I don't think that is suitable use for config option. > >I don't care much if we use "platform:" or no prefix at all for > >backlight of internal keyboard, as long as it is consistent across all > >devices. > > > >We certainly want to use some prefix (probably inputX:) for backlight > >on USB keyboards. >=20 > For LEDs exposed through the input-LED bridge my get_led_device_info.sh > script nicely reports: >=20 > associated input node: input1 >=20 > It just does: >=20 > readlink input1\:\:numlock/device >=20 > which prints: "../../input1 " Yes, that will probably work for USB keyboards. (But not for internal keyboards on phones, etc). Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlypJZQACgkQMOfwapXb+vJtUACcDprz07bWGG7owVUANpYCh1Dn nncAn3OE1uj6KGpEPmzK7C18vf/0BB89 =6fQc -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--