[REGRESSION] thermal: per-zone hwmon names break Steam Deck fan control

[REGRESSION] thermal: per-zone hwmon names break Steam Deck fan control

[Matthew Schwartz]

Hello,

After upgrading my Steam Deck OLED to a 7.2-rc kernel, the userspace fan control daemon that I use stopped working. I bisected the regression to d6323469bcfb ("thermal: hwmon: Register a hwmon device for each thermal zone").

Before this commit, the ACPI thermal-zone hwmon name was acpitz, while after the change it is now acpitz_0.

The device profiles for fan control rely on the exact `acpitz` hwmon naming like the below code snippet:

devices:
  - hwmon_name: acpitz
    nice_name: CPU
    max_temp: 90
    temp_hysteresis: 0
    sensor_name: temp1

So now, the profile fails to load with:

fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
fancontrol.py[40528]: Traceback (most recent call last):
fancontrol.py[40528]:   File "/usr/share/jupiter-fan-control/fancontrol.py", line 606, in <module>
fancontrol.py[40528]:     raise FileNotFoundError("Failed to load hwmons after 10 attempts.")
fancontrol.py[40528]: FileNotFoundError: Failed to load hwmons after 10 attempts.

Because initialization fails, the daemon never enters its fan-control loop or writes the requested fan target.

This change was also backported to Linux 7.1.5 as commit 996957016bc1, so the regression is present there as well and has led to a userspace ABI regression. I can look at accommodating the change on the userspace side, but it still seemed worth reporting as a kernel regression.

Thanks,
Matt

#regzbot introduced: d6323469bcfbda91f0aa89b7b39ad45fe822ca5d 

Re: [REGRESSION] thermal: per-zone hwmon names break Steam Deck fan control

[Rafael J. Wysocki (Intel)]

Hi,

On Wed, Jul 29, 2026 at 10:50 PM Matthew Schwartz
<matthew.schwartz@linux.dev> wrote:
>
> Hello,
>
> After upgrading my Steam Deck OLED to a 7.2-rc kernel, the userspace fan control daemon that I use stopped working. I bisected the regression to d6323469bcfb ("thermal: hwmon: Register a hwmon device for each thermal zone").
>
> Before this commit, the ACPI thermal-zone hwmon name was acpitz, while after the change it is now acpitz_0.
>
> The device profiles for fan control rely on the exact `acpitz` hwmon naming like the below code snippet:
>
> devices:
>   - hwmon_name: acpitz
>     nice_name: CPU
>     max_temp: 90
>     temp_hysteresis: 0
>     sensor_name: temp1
>
> So now, the profile fails to load with:
>
> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> fancontrol.py[40528]: Traceback (most recent call last):
> fancontrol.py[40528]:   File "/usr/share/jupiter-fan-control/fancontrol.py", line 606, in <module>
> fancontrol.py[40528]:     raise FileNotFoundError("Failed to load hwmons after 10 attempts.")
> fancontrol.py[40528]: FileNotFoundError: Failed to load hwmons after 10 attempts.
>
> Because initialization fails, the daemon never enters its fan-control loop or writes the requested fan target.
>
> This change was also backported to Linux 7.1.5 as commit 996957016bc1, so the regression is present there as well and has led to a userspace ABI regression. I can look at accommodating the change on the userspace side, but it still seemed worth reporting as a kernel regression.
>
> Thanks,
> Matt
>
> #regzbot introduced: d6323469bcfbda91f0aa89b7b39ad45fe822ca5d

Thanks for the report!

I think that commit d6323469bcfb will need to be reverted.

Re: [REGRESSION] thermal: per-zone hwmon names break Steam Deck fan control

[Armin Wolf]

Am 30.07.26 um 11:33 schrieb Rafael J. Wysocki (Intel):

> Hi,
>
> On Wed, Jul 29, 2026 at 10:50 PM Matthew Schwartz
> <matthew.schwartz@linux.dev> wrote:
>> Hello,
>>
>> After upgrading my Steam Deck OLED to a 7.2-rc kernel, the userspace fan control daemon that I use stopped working. I bisected the regression to d6323469bcfb ("thermal: hwmon: Register a hwmon device for each thermal zone").
>>
>> Before this commit, the ACPI thermal-zone hwmon name was acpitz, while after the change it is now acpitz_0.
>>
>> The device profiles for fan control rely on the exact `acpitz` hwmon naming like the below code snippet:
>>
>> devices:
>>    - hwmon_name: acpitz
>>      nice_name: CPU
>>      max_temp: 90
>>      temp_hysteresis: 0
>>      sensor_name: temp1
>>
>> So now, the profile fails to load with:
>>
>> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
>> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
>> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
>> fancontrol.py[40528]: Traceback (most recent call last):
>> fancontrol.py[40528]:   File "/usr/share/jupiter-fan-control/fancontrol.py", line 606, in <module>
>> fancontrol.py[40528]:     raise FileNotFoundError("Failed to load hwmons after 10 attempts.")
>> fancontrol.py[40528]: FileNotFoundError: Failed to load hwmons after 10 attempts.
>>
>> Because initialization fails, the daemon never enters its fan-control loop or writes the requested fan target.
>>
>> This change was also backported to Linux 7.1.5 as commit 996957016bc1, so the regression is present there as well and has led to a userspace ABI regression. I can look at accommodating the change on the userspace side, but it still seemed worth reporting as a kernel regression.
>>
>> Thanks,
>> Matt
>>
>> #regzbot introduced: d6323469bcfbda91f0aa89b7b39ad45fe822ca5d
> Thanks for the report!
>
> I think that commit d6323469bcfb will need to be reverted.

Would it be possible to instead make the new behavior depend on a Kconfig option?
This way we would give userspace time to adapt to the new behavior. Removing it completely
would mean that userspace will newer adapt.

Thanks,
Armin Wolf

Re: [REGRESSION] thermal: per-zone hwmon names break Steam Deck fan control

[Rafael J. Wysocki (Intel)]

On Thu, Jul 30, 2026 at 6:46 PM Armin Wolf <W_Armin@gmx.de> wrote:
>
> Am 30.07.26 um 11:33 schrieb Rafael J. Wysocki (Intel):
>
> > Hi,
> >
> > On Wed, Jul 29, 2026 at 10:50 PM Matthew Schwartz
> > <matthew.schwartz@linux.dev> wrote:
> >> Hello,
> >>
> >> After upgrading my Steam Deck OLED to a 7.2-rc kernel, the userspace fan control daemon that I use stopped working. I bisected the regression to d6323469bcfb ("thermal: hwmon: Register a hwmon device for each thermal zone").
> >>
> >> Before this commit, the ACPI thermal-zone hwmon name was acpitz, while after the change it is now acpitz_0.
> >>
> >> The device profiles for fan control rely on the exact `acpitz` hwmon naming like the below code snippet:
> >>
> >> devices:
> >>    - hwmon_name: acpitz
> >>      nice_name: CPU
> >>      max_temp: 90
> >>      temp_hysteresis: 0
> >>      sensor_name: temp1
> >>
> >> So now, the profile fails to load with:
> >>
> >> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> >> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> >> fancontrol.py[40528]: Warning: hwmons not fully loaded, retrying...
> >> fancontrol.py[40528]: Traceback (most recent call last):
> >> fancontrol.py[40528]:   File "/usr/share/jupiter-fan-control/fancontrol.py", line 606, in <module>
> >> fancontrol.py[40528]:     raise FileNotFoundError("Failed to load hwmons after 10 attempts.")
> >> fancontrol.py[40528]: FileNotFoundError: Failed to load hwmons after 10 attempts.
> >>
> >> Because initialization fails, the daemon never enters its fan-control loop or writes the requested fan target.
> >>
> >> This change was also backported to Linux 7.1.5 as commit 996957016bc1, so the regression is present there as well and has led to a userspace ABI regression. I can look at accommodating the change on the userspace side, but it still seemed worth reporting as a kernel regression.
> >>
> >> Thanks,
> >> Matt
> >>
> >> #regzbot introduced: d6323469bcfbda91f0aa89b7b39ad45fe822ca5d
> > Thanks for the report!
> >
> > I think that commit d6323469bcfb will need to be reverted.
>
> Would it be possible to instead make the new behavior depend on a Kconfig option?

Yes, it would, but I'm not sure I want to go down that path.

There is a major weakness in the new scheme, which I didn't take into
consideration, that it builds hwmon interface names using thermal zone
IDs which span all of the thermal zones in the system, not just
thermal zones of the same type, so what user space gets basically
depends on the initialization ordering.  Granted, this can be fixed,
but then is it really a good idea to register a hwmon class device
under a thermal class device?

I'm still thinking that in the future it would be good to give parents
to thermal zones, in which case hwmon class devices should be
registered under those parents.

> This way we would give userspace time to adapt to the new behavior. Removing it completely
> would mean that userspace will newer adapt.

But IMV it would be better to ask them to adapt just once.  So if the
plan is to arrange things to register thermal zones under specific
parents, that is what user space will need to adapt to and
intermediate adaptation episodes should be avoided, so to speak.

In the interim though there is the bug causing thermal zone removal to
deadlock due to the misdesigned hwmon interface which needs to be
addressed in the short term, possibly without disturbing user space.

To that end, I'm thinking about creating a faux device called, say,
thermal_sensors that will be used as the parent for all of the hwmon
class devices created automatically by the thermal core.