Re: [PATCH v4 fwctl 0/3] fwctl/bnxt: DMA buffer support for HWRM commands

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Jul 02, 2026 at 11:21:22AM +0530, Pavan Chebbi wrote:
> Several HWRM (HardWare Resource Manager) commands used for diagnostics,
> firmware management, and NVM access carry one or more DMA address fields
> in their input structures.  Until now these commands could not be issued
> through the fwctl interface because the driver had no mechanism to safely
> broker the host-side DMA buffers on userspace's behalf.
> 
> This series adds that mechanism in three steps.
> 
> In patch #1, the fwctl core UAPI adds a new driver_data field in struct
> fwctl_rpc.  Drivers that need a driver_data payload receive the value and
> are free to interpret it. Drivers that do not define one will reject any
> non-zero value with -EOPNOTSUPP.  Existing mlx5 and pds fwctl drivers are
> updated accordingly.
> 
> In patch #2, the bnxt HSI header is updated to add the missing struct
> definitions for the HWRM commands that the bnxt fwctl driver will support.
> 
> In patch #3, the bnxt fwctl driver consumes driver_data as a pointer to
> a new bnxt UAPI struct fwctl_bnxt_driver_data, which describes indirect
> DMA buffers.
> 
> v4: Collected Rb tag from Dave for patch #1. Thanks Dave

Sashiko had several things to say about v3:

https://sashiko.dev/#/patchset/20260526144507.822095-1-pavan.chebbi%40broadcom.com

For some reason v4 is mangled and it couldn't apply it.

And this one raises my eyebrows considering what we talked about before:

 How is dd.bufs[i].len ensured to match the actual transfer size expected
 by the firmware?
 If a small dd.bufs[i].len is provided while the HWRM command payload
 specifies a larger transfer size, could the firmware write past the end
 of the mapped bounce buffer into adjacent physical memory?

Seems like it needs a comment if it is actually safe somehow, but I
don't see how it is safe and it seems like Sashiko has hit on a
critical flaw.

Heh Sashiko also pointed out the broken device failure flow I
mentioned before too :)

Jason