On Mon, Mar 18, 2024 at 10:57:31PM +0100, Armin Wolf wrote: > Currently, the hp-wmi-sensors driver needs to be loaded manually > on supported machines. This however is unnecessary since the WMI > id table can be used to support autoloading. > > However the driver might conflict with the hp-wmi driver since both > seem to use the same WMI GUID for registering notify handler. > > I am thus submitting this patch as an RFC for now. > > Armin Wolf (1): > hwmon: (hp-wmi-sensors) Add missing MODULE_DEVICE_TABLE() > > drivers/hwmon/hp-wmi-sensors.c | 2 ++ > 1 file changed, 2 insertions(+) > > -- > 2.39.2 > Autoloading was deliberately left out for now because of the GUID conflict with hp-wmi's WMI notify handler. HP's GUID reuse across product lines for different types of WMI objects with different names and shapes means that with a patch like this, many systems that should only load hp-wmi-sensors but not hp-wmi will try to autoload both. (Perhaps all of them; I want to say that the GUID 5FB7F034-2C63-45e9-BE91-3D44E2C707E4, which is the second of the two GUIDs that hp-wmi uses to autoload, exists on every HP system I've examined.) Meanwhile, hp-wmi does various other platform things, and there's so much hardware out there that who knows, maybe there are some systems that really should load both. I don't think so but I can't rule it out. Unlike hp-wmi-sensors, hp-wmi doesn't survive failure to install its notify handler, which sets up a potential race condition depending on when hp-wmi and hp-wmi-sensors loads on a given system. Therefore, I intended to add autoloading at the same time as converting hp-wmi-sensors to use the bus-based WMI interface once aggregate WMI devices are better supported. As you mentioned [1], I ran into issues when I tried to do the conversion by simply adding the GUID to struct wmi_driver.id_table. That resulted in two separate independent instances of hp_wmi_sensors being loaded, which isn't what I wanted. [1] https://lore.kernel.org/linux-hwmon/cd81a7d6-4b81-f074-1f28-6d1b5300b937@xxxxxx/
