[RFC 9/9] {fwctl,drm}/xe/pcode: Introduce xe_pcode_fwctl

[Rodrigo Vivi]

On Wed, May 07, 2025 at 07:04:44PM -0300, Jason Gunthorpe wrote:
> On Wed, May 07, 2025 at 03:49:15PM -0400, Rodrigo Vivi wrote:
> 
> > One last thing since I have your attention here. Was any time in the previous
> > fwctl discussions talked about the possibility of some extra usages for like
> > FW flashing or in-field-repair/tests where big data needs to filled bypassing
> > lockdown mode?
> 
> For FW flash I do suggest you try to use devlink's firmware flashing
> interface. I think it would be really great if that could become a
> cross-subsystem standard in Linux.

I took a look there and I do believe devlink works very well for fw flashing and
it is also already prepared for basically any pci device without any change.
Thanks for the suggestion.

But now I have to ask you about 2 other use cases that are not under the
umbrella of: configuration and provisioning, but perhaps at least partially
under the umbrella of debug:

- In-field-test-and-repair
- Error injection

Can fwctl be used for these use cases, supposing that it FW mailboxes
commands and responses directly with no modification to the fwctl
infra itself?

in-field-test I'd say it is debug, the 'repair' portion is the most
questionable one. But error-injection I believe it is entirely
debug.

What's your thoughts and guidance here?

Thanks,
Rodrigo.

> 
> If that isn't going to work out then yes I would say fwctl should be
> considered for flashing.
> 
> Saeed's original version had a "big data" memory pinned DMA capable
> interface as well. With justification it could come into the fwctl
> version. I'm not against it, but mindful that it widens what is
> possible by quite a bit.
> 
> But you might not need something like that just for flash. Some
> internal improvement kernel side to allow streaming from large
> user-space RPC buffers instead of a single alloc and copy would be
> sufficient..
> 
> Jason