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] [day] [month] [year] [list]
Date:   Thu, 4 Apr 2019 22:34:08 +0200
From:   Pavel Machek <pavel@....cz>
To:     Dmitry Torokhov <dtor@...gle.com>
Cc:     Nick Crews <ncrews@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Benson Leung <bleung@...omium.org>, linux-leds@...r.kernel.org,
        jacek.anaszewski@...il.com,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Duncan Laurie <dlaurie@...omium.org>,
        Daniel Erat <derat@...gle.com>,
        Guenter Roeck <groeck@...gle.com>
Subject: Re: [PATCH] platform/chrome: Add Wilco EC keyboard backlight LEDs
 support

Hi!

> > > Because I need to understand why you believe that device name for
> > > kbd_backlight matters, and having wilco::kbd_backlight is a bad idea,
> > > but, for example, having max77650::kbd_backlight is perfectly fine if
> > > somebody decided to wire it in this way.
> >
> > max77650::kbd_backlight is not fine and we'll try to prevent that in
> > future.
> 
> You do not control DTS for systems though.

Actually we usually do. [And the name can still be fixed up in the driver.]

> > We want one name for internal keyboard backlight. What exactly that
> > name is is not _that_ important, but platform::kbd_backlight seems
> > like reasonable choice.
> 
> And I am trying to show that depending on device and product (as in
> entire computing device) the same driver could be used in multitude of
> ways and expecting that all devices that can be internal will always
> have "platform::" prefix is not realistic. It will also fail if you
> have multiples of devices, as you need unique names, and that is what
> <device> component in name provides you with.

I don't see what you are saying.

We know that wilco::kbd_backlight is always internal keyboard
backlight, so we name it platform::kbd_backlight. We do the same for
similar drivers in future. I don't see any downsides.

> You need smarter userspace to implement policy that is best suited for
> your product. Maybe you can help it by adding additional properties to
> LED devices, like we have connection_type in USB ports, to tell
> whether device is internal or not, but I'd leave the naming alone.

We may need smarter userspace, but it does not mean naming needs to
make it harder than it already is.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists