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