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.
