Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor
From: Jihong Min
Date: Wed May 06 2026 - 18:42:09 EST
> 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.
Addressed locally for v3. I changed the commit message, Kconfig prompt/help
text, and hwmon documentation to use the full name, "AMD Promontory 21
(PROM21)".
I avoided putting chipset marketing names directly into the Kconfig text and
commit subject because some AMD 6xx/8xx series chipsets can be built from more
than one PROM21 IP in a daisy-chained configuration, including more than one
PROM21 xHCI controller. I described that relationship in the hwmon
documentation instead.
> Is there any documentation of the index/data registers themselves?
I am not aware of public AMD documentation for the PROM21 vendor index/data
registers or the temperature selector.
For my initial validation on an X870E system with two PROM21 xHCI controllers,
I passed one PROM21 xHCI controller through to a Windows VM, left USB traffic
idle, and let a Windows monitoring utility poll the controller temperature.
From the Linux host I monitored that controller's PCI MMIO BAR with read-only
accesses. The vendor index register repeatedly held the same selector value,
and the adjacent data register exposed a stable low 8-bit value. That value
matched the reported PROM21 xHCI temperature after the conversion formula
below.
> Any potential danger that something else (FW? SMM?) uses them too?
I did not find any other in-kernel user of this PROM21 vendor index/data
register pair or the temperature selector.
The driver only serializes its own accesses. It saves the previous index,
selects the temperature register, reads the data register, restores the
previous index, and keeps the sequence short. This avoids leaving the vendor
index/data pair in a different state for other OS code.
This cannot synchronize against firmware or SMM. I cannot rule out such access
without AMD documentation or confirmation, so I would appreciate AMD feedback
on whether this PROM21 vendor index/data register pair is safe for OS polling.
I also tested concurrent temperature reads while USB traffic was active on the
same controller, including fio against an external USB storage device and
isochronous USB audio playback/capture. I did not observe USB transfer errors
or audio glitches in those tests.
> 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????!!!?
After identifying the register pair, I used the same validation setup to derive
the conversion formula by comparing the observed raw MMIO register value
against HWiNFO64's reported PROM21 xHCI temperature on Windows.
This worked because the PROM21 xHCI temperature is very stable at idle and the
sensor appears to have low resolution, so the value usually stays unchanged
long enough to compare both sides reliably.
> Is such behavior useful?
>
> Maybe the driver could just disable runtime PM while it's loaded.
and:
> 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.
I changed the local v3 branch to follow the amdgpu-style behavior by default.
The driver now does not wake the xHCI PCI device for a normal hwmon read. If
the device is already active, the read returns valid data. If the device is
suspended, the read returns -EPERM, matching the error code currently returned
by amdgpu's pm_runtime_get_if_active() based path. I used -EPERM to match the
current amdgpu precedent, but I can change the errno if maintainers prefer a
different one for this driver.
I kept the allow_pm_switch module parameter for now, but changed its default to
false. With the default setting, hwmon reads do not change the device runtime PM
state. Setting allow_pm_switch=Y explicitly opts into waking the xHCI PCI
device for temperature reads.
Thank you,
Jihong Min
On 5/7/26 06: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 valueI 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 PCIIs there any documentation of the index/data registers themselves?
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.
Any potential danger that something else (FW? SMM?) uses them too?
The conversion formula is derived from observed temperature readings:Could make sense to describe methodology, particularly in case some
temp[C] = raw * 0.9066 - 78.624
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 xHCIIs such behavior useful?
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.
Maybe the driver could just disable runtime PM while it's loaded.
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>