From: Mario Limonciello <mario.limonciello@amd.com>
To: Michal Pecio <michal.pecio@gmail.com>
Cc: Jihong Min <hurryman2212@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mathias Nyman <mathias.nyman@intel.com>,
Guenter Roeck <linux@roeck-us.net>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Basavaraj Natikar <Basavaraj.Natikar@amd.com>,
linux-usb@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-doc@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor
Date: Thu, 7 May 2026 08:24:56 -0500 [thread overview]
Message-ID: <d1132b52-153f-4451-9aff-ab2545e1a3d0@amd.com> (raw)
In-Reply-To: <20260507110821.07480da8.michal.pecio@gmail.com>
On 5/7/26 04:08, Michal Pecio wrote:
> On Wed, 6 May 2026 16:36:49 -0500, Mario Limonciello wrote:
>>>> 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
>
> Well, that's not a dGPU but an xHCI controller embedded in the chipset,
> which chipset is more or less active all the time (includes bridges to
> PCIe ports, some SATA controllers and mabe other things I forgot).
> Is the saving from disabling xHCI significant for a desktop system?
>
> Users may be interested in monitoring chipset temperature even while
> not actively using USB.
>
> I don't know what are the conditions to put GPUs into runtime suspend,
> but a USB HC will be going in and out quite randomly, depending on
> connected devices and their workload. You may end up needing to answer
> people why their sensor only works when they turn on a webcam :)
Heh. You have a good point here. The reason for this policy in dGPUs
came from a lot of people using them "headless" (for example plugging in
a display to the iGPU on the board) and wondering why randomly their
power shot up and fans spun up on the GPU. It took a while to narrow
down that it was specifically sensor software doing it.
For a sensor accessed through registers on XHCI this is a lot less of a
big deal for all the reasons you point out.
>
> Alternatively, would it be possible to bring a suspendend HC into D0,
> read the temperature register and then put it back into D3hot without
> bothering the USB layer to fully resume and suspend xHCI logic?
>
This sounds better to me if it's feasible.
next prev parent reply other threads:[~2026-05-07 13:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 3:29 [PATCH] usb: xhci: add AMD PROM21 xHCI hwmon support for temperature monitoring Jihong Min
2026-05-06 4:07 ` sashiko-bot
2026-05-06 13:37 ` Mathias Nyman
2026-05-06 14:26 ` Guenter Roeck
2026-05-06 20:28 ` Jihong Min
2026-05-06 20:40 ` [PATCH v2 0/2] AMD PROM21 xHCI temperature hwmon support Jihong Min
2026-05-06 20:40 ` [PATCH v2 1/2] usb: xhci-pci: add generic auxiliary device interface Jihong Min
2026-05-06 20:53 ` Mario Limonciello
2026-05-06 21:09 ` Jihong Min
2026-05-06 21:15 ` Michal Pecio
2026-05-06 21:42 ` Jihong Min
2026-05-06 20:40 ` [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor Jihong Min
2026-05-06 21:33 ` Michal Pecio
2026-05-06 21:36 ` Mario Limonciello
2026-05-07 9:08 ` Michal Pecio
2026-05-07 13:24 ` Mario Limonciello [this message]
2026-05-06 22:41 ` Jihong Min
2026-05-07 8:51 ` Michal Pecio
2026-05-06 22:17 ` Randy Dunlap
2026-05-06 22:52 ` Jihong Min
2026-05-07 3:29 ` Jihong Min
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d1132b52-153f-4451-9aff-ab2545e1a3d0@amd.com \
--to=mario.limonciello@amd.com \
--cc=Basavaraj.Natikar@amd.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=hurryman2212@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
--cc=skhan@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox