Am 27.09.24 um 13:24 schrieb Werner Sembach:
Hi,
an additional question below
Am 27.09.24 um 08:59 schrieb Werner Sembach:
Hi,
Am 26.09.24 um 20:39 schrieb Armin Wolf:
Am 26.09.24 um 19:44 schrieb Werner Sembach:
[...]
+// We don't know if the WMI API is stable and how unique the GUID
is for this ODM. To be on the safe
+// side we therefore only run this driver on tested devices
defined by this list.
+static const struct dmi_system_id tested_devices_dmi_table[] = {
+ {
+ // TUXEDO Sirius 16 Gen1
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "APX958"),
+ },
+ },
+ {
+ // TUXEDO Sirius 16 Gen2
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "AHP958"),
+ },
+ },
+ { }
+};
+
+static int probe(struct wmi_device *wdev, const void
__always_unused *context)
+{
+ struct tuxedo_nb04_wmi_driver_data_t *driver_data;
+
+ if (dmi_check_system(tested_devices_dmi_table))
+ return -ENODEV;
Hi,
please do this DMI check during module initialization. This avoids
having an useless WMI driver
on unsupported machines and allows for marking
tested_devices_dmi_table as __initconst.
I wonder how to do it since I don't use module_init manually but
module_wmi_driver to register the module.
In this case you cannot use module_wmi_driver. You have to manually call wmi_driver_register()/wmi_driver_unregister()
in module_init()/module_exit().
Besides that, maybe a "force" module parameter for overriding the
DMI checking could be
useful?
Considering the bricking potential i somewhat want for people to look
in the source first, so i would not implementen a force module parameter.
Ok.
Kind regards,
Werner
