[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABXOdTcrQELWVc5SwPHAk6BP5wq=kQg6K_g-7p+Y73tPFAFTdQ@mail.gmail.com>
Date: Mon, 8 Apr 2019 06:31:44 -0700
From: Guenter Roeck <groeck@...gle.com>
To: Pavel Machek <pavel@....cz>
Cc: Dmitry Torokhov <dtor@...gle.com>,
Guenter Roeck <linux@...ck-us.net>,
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 <jacek.anaszewski@...il.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
linux-rtc@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
Duncan Laurie <dlaurie@...omium.org>,
Simon Glass <sjg@...gle.com>
Subject: Re: Keyboard backlight LED naming was Re: [PATCH v5 2/3]
platform/chrome: Add Wilco EC keyboard backlight LEDs support
On Mon, Apr 8, 2019 at 2:41 AM Pavel Machek <pavel@....cz> wrote:
>
> Hi!
>
> > > > > > This document also states "The naming scheme above leaves scope
> > > > > > for further attributes should they be needed". It does not permit,
> > > > > > however, to redefine one of the fields to mean "location", much less
> > > > > > the declaration that a devicename of "platform" shall refer to an
> > > > > > "internal" backlight, or that there shall be no more than one
> > > > > > "internal" backlight in a given system.
> > > > >
> > > > > "platform" is as good devicename as "wilco" or "chromeos".
> > > >
> > > > No, because "platform" is not a device, it is something that you are
> > > > trying to assign a magic meaning to.
> > >
> > > "chromeos" is not a device, either.
> >
> > I agree, it is not a device name. We do not assign any specific
> > meaning to it though. We could change it to "cros_ec" if so desired
> > and nothing should break.
>
> Yes. And you can also change it to "platform" and nothing will break
> :-). Can we end the discussion here?
>
> If not, lets take a look at existing names:
>
> ./drivers/platform/x86/asus-laptop.c: cdev->name = "asus::kbd_backlight";
> ./drivers/platform/x86/samsung-laptop.c: samsung->kbd_led.name = "samsung::kbd_backlight";
> ./drivers/platform/x86/thinkpad_acpi.c: .name = "tpacpi::kbd_backlight",
> ./drivers/platform/x86/toshiba_acpi.c: dev->kbd_led.name = "toshiba::kbd_backlight";
> ./drivers/platform/x86/asus-wmi.c: asus->kbd_led.name = "asus::kbd_backlight";
> ./drivers/platform/x86/dell-laptop.c: .name = "dell::kbd_backlight",
> ./drivers/platform/chrome/cros_kbd_led_backlight.c: cdev->name = "chromeos::kbd_backlight";
> ./drivers/hwmon/applesmc.c: .name = "smc::kbd_backlight",
> ./drivers/hid/hid-asus.c: drvdata->kbd_backlight->cdev.name = "asus::kbd_backlight";
> ./drivers/hid/hid-google-hammer.c: kbd_backlight->cdev.name = "hammer::kbd_backlight";
> ./drivers/input/misc/ims-pcu.c: "pcu%d::kbd_backlight", pcu->device_no);
>
> asus, samsung, toshiba, asus, dell, chromeos... Those are really not
> device names, either. But in these cases, LED is probably controlled
> by EC, or by ACPI BIOS talking to the EC. People usually call such
> devices "platform devices".
>
> (Linux Platform Device Driver - CodeProject
> https://www.codeproject.com/tips/1080177/linux-platform-device-driver
> A platform device is one which is hardwired on the board and hence not
> hot-pluggable. )
>
> You can take a look at discussion around micmute LED.
>
> Thus "platform" is quite suitable name in your case, and incidentaly,
> it will be more useful for userspace than "cros_ec".
>
No, it isn't. All those name are at least roughly associated with the
driver name, and they all do reflect the abbreviated driver name.
"platform" isn't, and is prone to duplicates.
If you want the location reflected in the led sysfs atttribute name,
say so. "platform" is neither a driver name nor a location. On a side
note, appending a number to the attribute name is not a good idea. In
addition to not being backward compatible, it would be prone to
renumbering at each reboot.
Guenter
> Pavel
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Powered by blists - more mailing lists