Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Kind regards,

Werner






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux