Re: [PATCH 0/2] Introduce DRM_RAS using generic netlink for RAS

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Fri, Nov 07, 2025 at 01:20:03PM -0700, Zack McKevitt wrote:
> 
> 
> On 11/6/2025 6:42 AM, Rodrigo Vivi wrote:
> > > 
> > > > Also, it is worth to mention that we have a in-tree pyynl/cli.py tool that entirely
> > > > exercises this new API, hence I hope this can be the reference code for the uAPI
> > > > usage, while we continue with the plan of introducing IGT tests and tools for this
> > > > and adjusting the internal vendor tools to open with open source developments and
> > > > changing them to support these flows.
> > > 
> > > I think it would be nice to see some accompanying userspace code that makes
> > > use of this implementation to have as a reference if at all possible.
> > 
> > We have some folks working on the userspace tools, but I just realized that
> > perhaps we don't even need that and we could perhaps only using the
> > kernel-tools/ynl as official drm-ras consumer?
> > 
> > $ sudo ynl --family drm_ras --dump list-nodes
> > [{'device-name': '00:02.0',
> >    'node-id': 0,
> >    'node-name': 'non-fatal',
> >    'node-type': 'error-counter'},
> >   {'device-name': '00:02.0',
> >    'node-id': 1,
> >    'node-name': 'correctable',
> >   'node-type': 'error-counter'}]
> > 
> > thoughts?
> > 
> 
> I think this is probably ok for demonstrating this patch's functionality,
> but some userspace code would be helpful as a reference for applications
> that might want to integrate this directly instead of relying on CLI tools.

It makes sense. So let's continue to have some IGT tool for this.

> 
> > > 
> > > As a side note, I will be on vacation for a couple of weeks as of this
> > > weekend and my response time will be affected.
> > 
> > Thank you,
> > Please let me know if you have further thoughts here, or if you see any blocker
> > or an ack to move forward with this path.
> > 
> > Thanks,
> > Rodrigo.
> > 
> 
> No further thoughts on the patch contents, I think it looks good. I see that
> Jakub posted some TODOs while I was away, so I assume there will be another
> iteration that I will take a look at if/when that comes in.

Yes, but the changes in the error counter is not that big, just some better iteration,
small fixes and a fixed driver API regarding the error ID and error string.

> 
> > > 
> > > Thanks,
> > > 
> > > Zack