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.

Reply via email to