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

On Thu, Jul 30, 2026 at 6:46=E2=80=AFPM Armin Wolf <[email protected]> wrote:
>
> Am 30.07.26 um 11:33 schrieb Rafael J. Wysocki (Intel):
>
> > Hi,
> >
> > On Wed, Jul 29, 2026 at 10:50=E2=80=AFPM Matthew Schwartz
> > <[email protected]> wrote:
> >> Hello,
> >>
> >> After upgrading my Steam Deck OLED to a 7.2-rc kernel, the userspace f=
an control daemon that I use stopped working. I bisected the regression to =
d6323469bcfb ("thermal: hwmon: Register a hwmon device for each thermal zon=
e").
> >>
> >> 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 n=
aming 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/fancontro=
l.py", line 606, in <module>
> >> fancontrol.py[40528]:     raise FileNotFoundError("Failed to load hwmo=
ns after 10 attempts.")
> >> fancontrol.py[40528]: FileNotFoundError: Failed to load hwmons after 1=
0 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, b=
ut 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. Remov=
ing 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.