Re: [PATCH v5 0/2] AMD Promontory 21 xHCI temperature sensor support

[Mario Limonciello]

On 5/12/26 16:39, Jihong Min wrote:
> Hi,
>
> This series adds temperature monitoring for AMD Promontory 21 (PROM21)
> xHCI PCI functions.
>
> Patch 1 adds a small PROM21-specific xHCI PCI glue driver. USB host
> operation is delegated to the common xhci-pci code, while the PROM21 glue
> publishes an auxiliary device for optional sensor support.
>
> Patch 2 adds an auxiliary-bus hwmon driver that binds to that auxiliary
> device and exposes the PROM21 xHCI temperature value as temp1_input.
>
> The hwmon driver reads the sensor through a vendor index/data register pair
> in the xHCI PCI MMIO BAR. It does not wake the parent PCI device for hwmon
> reads; if the parent is suspended, the read returns -ENODATA.
>
> Changes in v5:
> - Add support for AMD 1022:43fc PROM21 xHCI controllers and document the
>    new PCI ID.
> - Make USB_XHCI_PCI_PROM21 depend on X86 and default to USB_XHCI_PCI.
> - Keep the PROM21 PCI glue built-in-only when enabled, while allowing the
>    hwmon sensor driver to be built as a separate module.
> - Move PROM21 xHCI PCI device IDs to xhci-pci.h so xhci-pci.c and
>    xhci-pci-prom21.c use shared definitions.
> - Pass the parent PCI device, MMIO base, and resource length to the hwmon
>    driver through platform data defined in a common header, instead of
>    inspecting the parent driver's drvdata from the hwmon driver.
> - Remove the private hwmon mutex and rely on hwmon core serialization for
>    this driver's callbacks.
> - Clarify that the driver only serializes its own hwmon callbacks and does
>    not synchronize with firmware, SMM, ACPI AML, or other possible users of
>    the PROM21 vendor index/data register pair.
> - Use readb() for the temperature data register, validate the value before
>    writing the output pointer, and drop the 0xff invalid-value check.
> - Use pm_runtime_put() after successful reads with the parent device active
>    so the PM core can re-evaluate the parent device's idle state.
> - Simplify the documentation and use more precise terminology for the
>    supported device.
>
> Jihong Min (2):
>    usb: xhci-pci: add AMD Promontory 21 PCI glue
>    hwmon: add AMD Promontory 21 xHCI temperature sensor support
>
>   Documentation/hwmon/index.rst                 |   1 +
>   Documentation/hwmon/prom21-xhci.rst           | 101 ++++++++
>   drivers/hwmon/Kconfig                         |  10 +
>   drivers/hwmon/Makefile                        |   1 +
>   drivers/hwmon/prom21-xhci.c                   | 238 ++++++++++++++++++
>   drivers/usb/host/Kconfig                      |  20 ++
>   drivers/usb/host/Makefile                     |   1 +
>   drivers/usb/host/xhci-pci-prom21.c            | 123 +++++++++
>   drivers/usb/host/xhci-pci.c                   |  11 +
>   drivers/usb/host/xhci-pci.h                   |   3 +
>   include/linux/platform_data/usb-xhci-prom21.h |  22 ++
>   11 files changed, 531 insertions(+)
>   create mode 100644 Documentation/hwmon/prom21-xhci.rst
>   create mode 100644 drivers/hwmon/prom21-xhci.c
>   create mode 100644 drivers/usb/host/xhci-pci-prom21.c
>   create mode 100644 include/linux/platform_data/usb-xhci-prom21.h

Thanks for the driver.  I think this looks good now, and thank you 
especially for documenting your reverse engineering efforts that led to 
it.  If there are problems in the future I'm supposing it's going to be 
based upon the calculations with the magic values to scale numbers.

There isn't a lot that can be done in the event that BIOS is accessing 
the same register pairs, but since you identified that this is exactly 
how Windows HWInfo64 does it too; this is 'probably' low risk.

Reviewed-by: Mario Limonciello (AMD) <superm1@xxxxxxxxxx>