Re: [PATCH] platform/chrome: Add Wilco EC keyboard backlight LEDs support

[Pavel Machek]

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

Attachment: signature.asc
Description: Digital signature