Re: Adding a new platform driver samsung-galaxybook

[Lee Jones <lee@kernel.org>]

> > For specifically kbd_backlight and hwmon devices, I think it is more
> > likely that people will be making various scripts / config / etc that
> > do things like show the fan speeds in various widgets and/or control
> > the keyboard backlight via script, so it seems to me like it is even
> > better if these can be fixed names that anyone who uses these devices
> > will be able to use (e.g. "samsung-galaxybook::kbd_backlight" feels
> > better than something non-fixed based on ACPI device ID like
> > "SAM0429_00::kbd_backlight").
> > 
> > This feels a bit like sub-optimizing here, especially since pretty
> > much all of the other drivers I can see are hard-coding these kind of
> > names already as well.. is it ok to just leave hwmon and LED class
> > device names as hard-coded with prefix "samsung-galaxybook" and
> > if/when it comes along that someone has a problem with multiple
> > instances, it will fail with an error message in the kernel log and
> > they can submit a bug? (where we figure out what the right course of
> > action is exactly for that case)
> 
> I am CCing the LED maintainers so they can give us some advise on how to handle
> this the best way.

I'm only in receipt of a snippet of the conversation here and lack all
context, however I can speak generally.

It is unlikely that you find yourself in uncharted territory with
respect to device enumeration and future-proofing.  The kernel is
designed in such a way as to support subsequent versions of devices,
usually by versioning or literal enumeration (see PLATFORM_DEVID_AUTO as
an example of this).  Allowing future devices to break and subsequently
relying on users to submit bug reports sounds suboptimal.  If we can
prevent breakage rather than react to it, possibly after developers have
moved on to something else, then we should do that. Matching on known
ACPI implementations and providing support for that sounds sane.

-- 
Lee Jones [李琼斯]