Re: [PATCH 0/6] drm/nouveau: GSP telemetry via RUSD, and fdinfo telemetry exposure

[Milos Tijanic <mtijanic@nvidia.com>]

On Wed, 2026-07-15 at 01:14 +0400, Mohamed Ahmed wrote:
> A section that has
> not been polled yet, or that the board does not support, reads
> -ENODATA.

Per hwmon/sysfs-interface.rst: "All entries (except name) are optional,
and should only be created in a given driver if the chip has the
feature."

It feels really weird to have a bunch of things there that just give an
error code when reading. Does anything else use this pattern?

>   - The sysfs interface exposed here should be stable and valid for
> nova as well.

Agreed. Please allow a bit of time for us to review the uAPI for Nova
and future GSP versions.

>  RUSD is stable and only grows more fields with newer GSP firmware
> (e.g., fan telemetry gets added in r580), so it is possible   to keep
> the same interface as we use newer firmware

Don't assume this. Work is underway to significantly rework the RUSD
layout to make it extensibe in ABI-compatible ways, but there will be
a single large ABI break compared to 570. This will happen when we add
RUSD support to Nova, so it's some months out still.

>   - amdgpu offers a single binary blob with all the telemetry
> embedded in
>    addition to the sysfs sensor files. This series currently only
> exposes
>     sensor files, but it is possible to add a similar binary for a
> v2.
>     This mainly offers a more efficient way to read the telemetry as
>     clients would read only a few files instead of reading all of
> them.

IIUC the reason amdgpu does that is so you can take a self-consistent
atomic snapshot of all the telemetry readings. That's just not how RUSD
works, so we don't need/want it.

We don't want to expose binary RUSD to userspace while it is unstable.
Once it does become stable, the way this was meant to be exposed is to
allow userspace to RO mmap the buffer and read the telemetry directly,
with no syscall overhead. But I'm kind of loathe to do that even with
the new format as it will require some parsing and that's easy to get
wrong on the userspace side and still work in a given version, then
break with an update.

We can revisit this when ABI-stable RUSD comes, and then maybe have a
reference librusd that does the parsing.