Re: sch5627 on Fujitsu Celsius W280

Re: sch5627 on Fujitsu Celsius W280

[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

Re: sch5627 on Fujitsu Celsius W280

[Armin Wolf]

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.

Armin Wolf

Re: sch5627 on Fujitsu Celsius W280

[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
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.

Guenter

Re: sch5627 on Fujitsu Celsius W280

[Armin Wolf]

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

Re: sch5627 on Fujitsu Celsius W280

[Ian Nartowicz]

On Tue, 24 Oct 2023 07:48:50 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

>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
>

Apologies for the spam.  I didn't know about the mailing list.  Hopefully this
will be more correct.

I tried the ignore_dmi option.  Used manually on sch56xx-common, I was then
able to modprobe sch5627 and it started working.  Slightly clumsy, loading
sch5627 first wouldn't work. It all worked more smoothly with the modules built
in to the kernel and the option on the command line.

I have no idea how many machines use this chip, but I can't imagine the current
list is comprehensive.  Quite old, though?  Let me know if you need more data
or testing on a relevant machine.

--ian