[RFC v5 1/5] drm/netlink: Add netlink infrastructure
Zack McKevitt
zachary.mckevitt at oss.qualcomm.com
Mon Aug 25 17:31:49 UTC 2025
On 8/21/2025 3:45 AM, Aravind Iddamsetty wrote:
> Glad to know the interest, at present the code does create drm netlink
> family for accel device as well, but it is tries to register with the
> drm primary node name which might not be present for dev->accel,
> checking for the "DRIVER_COMPUTE_ACCEL" and registering with the name
> will fix that.
This is correct, trying to access dev->primary->kdev->kobj.name through
an accel device will cause a fault. I believe your solution will work,
and the node name can instead be retrieved via dev->accel->kdev->kobj.name.
> But also to bring to your attention the current series focuses on
> reporting RAS errors and hence the commands are as well oriented towards
> errors, anything specific to telemetry needs to be added. Do you have
> any thought as to what kind of data and what kind of command support you
> might need.
Understood. We will likely be interested in RAS functionality in the
future but thought this would be a good avenue for telemetry as well
since our device currently has a functional RAS implementation.
An early prototype for this might add a new command for telemetry and a
new policy with 4 new attributes: the type of telemetry to read/write
(e.g., SoC temp), whether the request is a read or write from/to the
device, the status of the request, and the telemetry value read or
written. As actual telemetry fields are likely device specific, these
can be defined in the driver's uapi header and passed opaquely through
the netlink interface.
The above description was sufficient for an initial prototype on top of
our driver. Mostly, however, we want to reiterate our interest in these
changes and will keep an eye out for a future patchset that incorporates
generated boilerplate from a YAML description.
Thanks again,
Zack
> Thanks,
> Aravind.
More information about the Intel-xe
mailing list