}
/* dell-rbtn.c driver export functions which will not work
correctly (and could
diff --git a/drivers/platform/x86/dell/dell-smbios-base.c
b/drivers/platform/x86/dell/dell-smbios-base.c
index 6ae09d7f76fb..387fa5618f7a 100644
--- a/drivers/platform/x86/dell/dell-smbios-base.c
+++ b/drivers/platform/x86/dell/dell-smbios-base.c
@@ -71,6 +71,7 @@ static struct smbios_call call_blacklist[] = {
/* handled by kernel: dell-laptop */
{0x0000, CLASS_INFO, SELECT_RFKILL},
{0x0000, CLASS_KBD_BACKLIGHT, SELECT_KBD_BACKLIGHT},
+ {0x0000, CLASS_INFO, SELECT_THERMAL_MANAGEMENT},
};
So when Alex checked on v5 that this doesn't load on workstations, it
has made me realize that doing this will block the interface totally
even on workstations.
So I think there are a few ways to go to handle this:
1) Rename dell-laptop to dell-client or dell-pc and let dell-laptop
load on more form factors. This would require some internal handling
in the module for which features make sense for different form
factors.
2) Add a new module just for the thermal handling and put all this
code into it instead.
I don't have a strong opinion, but I do think one of them should be
done to ensure there aren't problems on workstations losing access to
thermal control.
My apologies, I accidentally sent my response in HTML format. Please
see plain-text below:
Thinking about it more, we can leave dell-laptop as-is and create a
common dell-pc module that does not check for specific form-factors,
assuming that is possible. Thermal management can be the first function
to go in there.
We will still block the calls from userspace regardless of which
modules are loaded. If dell-pc fails because thermal management is not
supported, we aren't losing anything by blocking that call anyway.
Thoughts?
