Re: [PATCH RESEND v1] thermal: core: fix blocking in unregistering zone

[Rafael J. Wysocki]

On Fri, Apr 3, 2026 at 4:20 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> On 4/3/26 05:52, Rafael J. Wysocki wrote:
> .[ ... ]
> > It appears to work for me, but I'm not sure if having multiple hwmon class
> > devices with the same value in the name attribute is fine.
>
> Like this ?
>
> $ cd /sys/class/hwmon
> $ grep . */name
> hwmon0/name:r8169_0_c00:00
> hwmon1/name:nvme
> hwmon2/name:nvme
> hwmon3/name:nct6687
> hwmon4/name:k10temp
> hwmon5/name:spd5118
> hwmon6/name:spd5118
> hwmon7/name:spd5118
> hwmon8/name:spd5118
> hwmon9/name:mt7921_phy0

Yes.

> Names such as "r8169_0_c00:00" and "mt7921_phy0" are actually overkill
> since the "sensors" command makes it
>
> r8169_0_c00:00-mdio-0
> Adapter: MDIO adapter
> temp1:        +36.0°C  (high = +120.0°C)
>
> mt7921_phy0-pci-0d00
> Adapter: PCI adapter
> temp1:        +30.0°C
>
> essentially duplicating the device index.

Well, with the patch posted by me, the output of sensors from a test
system looks like this:

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C

pch_cannonlake-virtual-0
Adapter: Virtual device
temp1:        +33.0°C

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C

(some further data excluded), which is kind of confusing (note the
duplicate acpitz-acpi-0 entries with different values of temp1).

That could be disambiguated by concatenating the thermal zone ID
(possibly after a '_') to the name.  Or the "temp*" things for thermal
zones of the same type could carry different numbers.

A less attractive alternative would be to register a special virtual
device serving as a parent for all hwmon interfaces registered
automatically for thermal zones.