linux-kernel - Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard backlight name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Apr 2019 14:48:35 -0700
From:   Dmitry Torokhov <dtor@...gle.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Nick Crews <ncrews@...omium.org>,
        Guenter Roeck <groeck@...gle.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>, linux-leds@...r.kernel.org,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        linux-rtc@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Duncan Laurie <dlaurie@...omium.org>,
        Simon Glass <sjg@...gle.com>
Subject: Re: [PATCH v5 3/3] platform/chrome: Standardize Chrome OS keyboard
 backlight name

On Thu, Apr 4, 2019 at 1:42 PM Pavel Machek <pavel@....cz> wrote:
>
> Hi!
>
> > > > And what to do if internal keyboard is not platform but USB? Like
> > > > Google "Whiskers"? (I am not sure why you decided to drop my mention
> > > > of internal USB keyboards completely off your reply).
> > >
> > > I don't have answers for everything. Even if you have USB keyboard, you'll
> > > likely still have backlight connected to embedded controller. If not,
> > > then maybe you have exception userland needs to know about.
> > >
> > > Still better than making everything an exception.
> >
> > You do not need to make everything exception. You just need to look
> > beyond the name, and see how the device is connected. And then apply
> > your exceptions for "weird" devices.
>
> "Where it is connected" is not interesting to the userland. "Is it
> backlight for internal keyboard" is the right question. It may be
> connected to embedded controller or some kind of controller over
> i2c... my shell scripts should not need to know about architecture of
> every notebook out there.

Then your scripts will be failing for some setups.

>
> But I don't see why I should do additional work when its trivial for
> kernel to just name the LED in an useful way.
>
> "platform::kbd_backlight" has no disadvantages compared to
> "wilco::kbd_backlight" ... so lets just use it.

It has disadvantages because it promises more than it can deliver IMO.
If device name != "platform::kbd_backlight" it does not mean that it
is not internal keyboard. And you still have not resolved how you will
handle cases when there is more than one deice that can be considered
internal and may have a backlight.

Thanks.

-- 
Dmitry