Having to maintain a per-system allowlist is burdensome and confusing
for users, drop it.
Signed-off-by: Thomas Weißschuh <[email protected]>
---
I propose to keep this in -next for two cycles or so to make sure it
does not break anything.
---
drivers/platform/x86/gigabyte-wmi.c | 40 -------------------------------------
1 file changed, 40 deletions(-)
diff --git a/drivers/platform/x86/gigabyte-wmi.c b/drivers/platform/x86/gigabyte-wmi.c
index 322cfaeda17b..b0338f043416 100644
--- a/drivers/platform/x86/gigabyte-wmi.c
+++ b/drivers/platform/x86/gigabyte-wmi.c
@@ -13,10 +13,6 @@
#define GIGABYTE_WMI_GUID "DEADBEEF-2001-0000-00A0-C90629100000"
#define NUM_TEMPERATURE_SENSORS 6
-static bool force_load;
-module_param(force_load, bool, 0444);
-MODULE_PARM_DESC(force_load, "Force loading on unknown platform");
-
static u8 usable_sensors_mask;
enum gigabyte_wmi_commandtype {
@@ -133,46 +129,10 @@ static u8 gigabyte_wmi_detect_sensor_usability(struct wmi_device *wdev)
return r;
}
-#define DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME(name) \
- { .matches = { \
- DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), \
- DMI_EXACT_MATCH(DMI_BOARD_NAME, name), \
- }}
-
-static const struct dmi_system_id gigabyte_wmi_known_working_platforms[] = {
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M DS3H-CF"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M DS3H WIFI-CF"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M S2H V2"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE AX V2"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE V2"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 GAMING X V2"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550I AORUS PRO AX"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550M AORUS PRO-P"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550M DS3H"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B660 GAMING X DDR4"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B660I AORUS PRO DDR4"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z390 I AORUS PRO WIFI-CF"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z490 AORUS ELITE AC"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 AORUS ELITE"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 AORUS ELITE WIFI"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 GAMING X"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 I AORUS PRO WIFI"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 UD"),
- DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z690M AORUS ELITE AX DDR4"),
- { }
-};
-
static int gigabyte_wmi_probe(struct wmi_device *wdev, const void *context)
{
struct device *hwmon_dev;
- if (!dmi_check_system(gigabyte_wmi_known_working_platforms)) {
- if (!force_load)
- return -ENODEV;
- dev_warn(&wdev->dev, "Forcing load on unknown platform");
- }
-
usable_sensors_mask = gigabyte_wmi_detect_sensor_usability(wdev);
if (!usable_sensors_mask) {
dev_info(&wdev->dev, "No temperature sensors usable");
---
base-commit: 65aca32efdcb0965502d3db2f1fa33838c070952
change-id: 20230325-gigabyte-wmi-unrestrict-7244320c1996
Best regards,
--
Thomas Weißschuh <[email protected]>
Hi Thomas,
On 3/25/23 17:48, Thomas Weißschuh wrote:
> Having to maintain a per-system allowlist is burdensome and confusing
> for users, drop it.
>
> Signed-off-by: Thomas Weißschuh <[email protected]>
> ---
>
> I propose to keep this in -next for two cycles or so to make sure it
> does not break anything.
I think dropping this is a good idea (given the current experience with
the driver), but keeping the dropping of the list in -next for 2 cycles
is somewhat tricky. Normally once the final e.g. 6.3 is released I take
the pdx86/for-next branch *as-is* and use that to send a pull-req to
Linus, so that Linus gets send a hash which has been tested in linux-next
for a while before sending it to him.
Dropping this patch at that point would mean generating a new hash,
which is a bit meh. I can do that but I would prefer to just limit
testing to 1 full cycle.
Maybe you can send me a non RFC version of this patch once 6.4-rc1 is out?
Then I can add that to for-next right away and then we can get a full
cycle of -next testing that way.
Would that work for you?
Regards,
Hans
> ---
> drivers/platform/x86/gigabyte-wmi.c | 40 -------------------------------------
> 1 file changed, 40 deletions(-)
>
> diff --git a/drivers/platform/x86/gigabyte-wmi.c b/drivers/platform/x86/gigabyte-wmi.c
> index 322cfaeda17b..b0338f043416 100644
> --- a/drivers/platform/x86/gigabyte-wmi.c
> +++ b/drivers/platform/x86/gigabyte-wmi.c
> @@ -13,10 +13,6 @@
> #define GIGABYTE_WMI_GUID "DEADBEEF-2001-0000-00A0-C90629100000"
> #define NUM_TEMPERATURE_SENSORS 6
>
> -static bool force_load;
> -module_param(force_load, bool, 0444);
> -MODULE_PARM_DESC(force_load, "Force loading on unknown platform");
> -
> static u8 usable_sensors_mask;
>
> enum gigabyte_wmi_commandtype {
> @@ -133,46 +129,10 @@ static u8 gigabyte_wmi_detect_sensor_usability(struct wmi_device *wdev)
> return r;
> }
>
> -#define DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME(name) \
> - { .matches = { \
> - DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), \
> - DMI_EXACT_MATCH(DMI_BOARD_NAME, name), \
> - }}
> -
> -static const struct dmi_system_id gigabyte_wmi_known_working_platforms[] = {
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M DS3H-CF"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M DS3H WIFI-CF"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B450M S2H V2"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE AX V2"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 AORUS ELITE V2"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550 GAMING X V2"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550I AORUS PRO AX"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550M AORUS PRO-P"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B550M DS3H"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B660 GAMING X DDR4"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("B660I AORUS PRO DDR4"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z390 I AORUS PRO WIFI-CF"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z490 AORUS ELITE AC"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 AORUS ELITE"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 AORUS ELITE WIFI"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 GAMING X"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 I AORUS PRO WIFI"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("X570 UD"),
> - DMI_EXACT_MATCH_GIGABYTE_BOARD_NAME("Z690M AORUS ELITE AX DDR4"),
> - { }
> -};
> -
> static int gigabyte_wmi_probe(struct wmi_device *wdev, const void *context)
> {
> struct device *hwmon_dev;
>
> - if (!dmi_check_system(gigabyte_wmi_known_working_platforms)) {
> - if (!force_load)
> - return -ENODEV;
> - dev_warn(&wdev->dev, "Forcing load on unknown platform");
> - }
> -
> usable_sensors_mask = gigabyte_wmi_detect_sensor_usability(wdev);
> if (!usable_sensors_mask) {
> dev_info(&wdev->dev, "No temperature sensors usable");
>
> ---
> base-commit: 65aca32efdcb0965502d3db2f1fa33838c070952
> change-id: 20230325-gigabyte-wmi-unrestrict-7244320c1996
>
> Best regards,
On 2023-03-27 15:15:06+0200, Hans de Goede wrote:
> Hi Thomas,
>
> On 3/25/23 17:48, Thomas Weißschuh wrote:
> > Having to maintain a per-system allowlist is burdensome and confusing
> > for users, drop it.
> >
> > Signed-off-by: Thomas Weißschuh <[email protected]>
> > ---
> >
> > I propose to keep this in -next for two cycles or so to make sure it
> > does not break anything.
>
> I think dropping this is a good idea (given the current experience with
> the driver), but keeping the dropping of the list in -next for 2 cycles
> is somewhat tricky. Normally once the final e.g. 6.3 is released I take
> the pdx86/for-next branch *as-is* and use that to send a pull-req to
> Linus, so that Linus gets send a hash which has been tested in linux-next
> for a while before sending it to him.
>
> Dropping this patch at that point would mean generating a new hash,
> which is a bit meh. I can do that but I would prefer to just limit
> testing to 1 full cycle.
>
> Maybe you can send me a non RFC version of this patch once 6.4-rc1 is out?
> Then I can add that to for-next right away and then we can get a full
> cycle of -next testing that way.
>
> Would that work for you?
Absolutely, will do.
Thanks,
Thomas