I think they'll never fix it or release information about the change.
What if we modify the driver to fallback to i8k_get_temp() if
i8k_get_temp_type()
fails as a probe method? Or we could add a module option to force that behavior.
Cheers,
Michele.
On 2/7/19 12:40 PM, Pali Rohár wrote:
Do you have definite response from Dell support that they are not going
to fix it? Then it is pity :-(
On Thursday 07 February 2019 12:16:06 Michele Sorcinelli wrote:
As far as I know Dell won't help with fixing the SMM layer, they probably
changed something starting with firmware version 1.3.0 and they don't
wanna release information about it.
https://www.hwinfo.com/forum/Thread-Dell-XPS-15-9570-temperatures-not-named-anymore
I wonder if something can be done to force the discovery of the sensors in the
driver,
maybe adding a module option to use i8k_get_temp() as probe method as a
workaround,
or maybe just forcing that method for this specific model?
Let me know your thoughts.
Thanks,
Michele.
On 12/10/18 10:58 AM, Pali Rohár wrote:
On Friday 07 December 2018 20:24:49 Guenter Roeck wrote:
Anyway, I would like to get some feedback if this can cause regressions
on systems which don't support that many sensors and maybe report something
completely different if one tries to read the high-numbered sensors.
I seem to recall that there was a reason for checking the type and not just
trying to read sensor values.
There can be also different problem for sensors which are turned off.
E.g. on notebooks with switchable graphic cards which have included
temperature sensors. When graphic card is turned off, then SMM returns
error when asking for temperature value (for obvious reason). But
temperature type still returns correct value "this is GPU sensors".
So we cannot replace temp_type check by temp_value check. It introduce
race condition between "starting GPU" and initializing dell-smm hwmon.
Now linux kernel has support for dynamic turning ON/OFF switchable GPU,
so we need to care about these race conditions too.
