> > 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 [李琼斯]
