On Mon, Aug 25, 2025 at 11:31:49AM -0600, Zack McKevitt wrote: > > > 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,
Hi Zack, thanks for your interest, could you please take a look in the new version and help with reviews and feedback there to see if that is flexible enough to be later expanded to your needs: https://lore.kernel.org/dri-devel/20250929214415.326414-5-rodrigo.v...@intel.com/ Thanks, Rodrigo. > > Zack > > > Thanks, > > Aravind.
