Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor

[Mario Limonciello]

On 5/6/26 16:33, Michal Pecio wrote:
> On Thu,  7 May 2026 05:40:34 +0900, Jihong Min wrote:
> > AMD PROM21 xHCI controllers expose an 8-bit temperature value
>
> I think this commit message and certainly the Kconfig help text should
> include full name of the chip and perhaps its official marketing names
> too, so that people better understand what hardware is supported.
>
> So: "AMD Promontory 21 chipset" and "AM5 6xx/8xx series chipsets", or
> whatever they are called by AMD and motherboard vendors.
>
> > through a vendor-specific index/data register pair in the xHCI PCI
> > MMIO BAR region. Add an auxiliary hwmon driver for AMD 1022:43fd
> > controllers and bind it to the xhci_pci.hwmon auxiliary device
> > created by xhci-pci.
> >
> > The read path verifies the parent PCI function and uses the
> > initialized xHCI HCD MMIO mapping. The vendor index register is at
> > byte offset 0x3000 from the xHCI MMIO BAR base and the vendor data
> > register is at byte offset 0x3008. The driver writes register selector
> > 0x0001e520 to the index register, reads the raw temperature value from
> > the low 8 bits of the data register, and restores the previous index
> > before returning. Expose temp1_input and an xHCI label through hwmon.
> >
> > Register the hwmon device under the parent PCI function so userspace
> > reports it as a PCI adapter, while the auxiliary driver still owns the
> > hwmon lifetime and unregisters it from the auxiliary remove path.
> >
> > No public AMD reference is available for this value.
>
> Is there any documentation of the index/data registers themselves?
>
> Any potential danger that something else (FW? SMM?) uses them too?
>
> > The conversion formula is derived from observed temperature readings:
> >
> >    temp[C] = raw * 0.9066 - 78.624
>
> Could make sense to describe methodology, particularly in case some
> people would come and question the formula.
>
> How was actual chip temperature measured?
> Was the output compared with any other (Windows?) utilities?
>
> People will be comparing these results and possibly trying to draw
> some conclusions, like OMG Linux runs this chip 8°C hotter, should
> I demand a full refund of my free Ubuntu download????!!!?
>
> > The temperature register did not return a valid value while the xHCI
> > PCI function was suspended in testing. Keep the existing behavior by
> > default and allow temperature reads to wake the xHCI PCI device. Add an
> > allow_pm_switch module parameter so users can disable that behavior;
> > when disabled, reads do not wake the device and return -EAGAIN if it is
> > suspended.
>
> Is such behavior useful?
>
> Maybe the driver could just disable runtime PM while it's loaded.

I'd encourage what we do in amdgpu for dGPUs. The hwmon files will 
return an error code (I forget which code) when the device is in runtime 
PM when called.  Don't explicitly wake it otherwise.

This prevents someone installing a sensor monitoring application and 
that application "being the only thing" keeping the dGPU awake.  If it's 
awake already for other reasons (like being used) then return valid data 
to the applications.

> > Document the supported device, register access, conversion formula,
> > module parameter, sysfs attributes, and sysfs lookup method.
> >
> > Assisted-by: Codex:gpt-5.5
> > Signed-off-by: Jihong Min <hurryman2212@xxxxxxxxx>