Am 24.10.23 um 20:21 schrieb Guenter Roeck:
On Tue, Oct 24, 2023 at 07:42:11PM +0200, Armin Wolf wrote:
Am 24.10.23 um 16:48 schrieb Guenter Roeck:
On 10/24/23 07:04, Ian Nartowicz wrote:
I just upgraded a Celsius W280 to the 6.1 kernel and noticed that
hardware
monitoring was gone. Was working in 5.10. When I added it to the
dmi_override_table, it started working again (with a slightly
different device
name). dmidecode shows it as an on board device, type other, status
disabled
(just the watchdog?), and description "SMsC SuperI/O".
Weird, this is the second private e-mail I get in a single day.
Is there some information out there suggesting that kernel maintainers
should be contacted without copying the mailing list ? If so, tell them
it is wrong. As warning to everyone, I won't reply any further
to private e-mails like this.
Looking at the code, try adding ignore_dmi=1 as module parameter when
loading the driver. I think commit 393935baa45e5c messed it up and
prevents the driver from loading if the parameter is not provided.
Maybe the conditions in sch56xx_init() are wrong or too generic.
Armin, any comments ? Do we need to revert your patch ?
Guenter
I think so, it seems that the DMI devices are not always present.
We better revert the DMI autodetection patch to prevent anymore
regressions like this.
Not sure what I'd need to revert. Would it be all of the following ?
fd2d53c367ae hwmon: (sch56xx-common) Add DMI override table
393935baa45e hwmon: (sch56xx-common) Add automatic module loading on supported devices
Those two commits should be reverted. The other commit is still useful without the DMI
autoloading, since it allows user to just load sch56xx-common without having to load
sch5627/sch5636 manually afterwards.
4db3c09228a0 hwmon: (sch56xx) Autoload modules on platform device creation
Alternatively, we could add Celsius W280 to the dmi override table.
After all, the code has been present since 6.1, and the functional
gain seems to be sufficient. Adding W280 with a Fixes: tag pointing
to fd2d53c367ae would make more sense to me than reverting the above
patches.
I fear that there are far more machines suffering from this exact same issue.
It seems to me now that the DMI device is only optional, possibly to signal the
availability of some sort of management technology of which the hwmon interface
seems to be part of.
We could solve this problem by somehow making it possible to send uevents if
DMI onboard devices are detected. They could then be used to load the necessary
drivers.
However since we currently cannot do this, i would revert the two patches for
the time being.
Armin Wolf
Guenter
