[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