linux-kernel - Re: [PATCH v3 fwctl 4/5] fwctl/bnxt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALs4sv2V0Hm2Do6WnQgHDuRpQYyi_g6ym0GbFe9rfV8Q6VEJ_g@mail.gmail.com>
Date: Thu, 5 Feb 2026 20:39:10 +0530
From: Pavan Chebbi <pavan.chebbi@...adcom.com>
To: Saeed Mahameed <saeedm@...dia.com>
Cc: jgg@...pe.ca, michael.chan@...adcom.com, linux-kernel@...r.kernel.org, 
	dave.jiang@...el.com, Jonathan.Cameron@...wei.com, gospo@...adcom.com, 
	selvin.xavier@...adcom.com, leon@...nel.org, 
	kalesh-anakkur.purayil@...adcom.com
Subject: Re: [PATCH v3 fwctl 4/5] fwctl/bnxt_fwctl: Add bnxt fwctl device

On Thu, Feb 5, 2026 at 9:55 AM Pavan Chebbi <pavan.chebbi@...adcom.com> wrote:
>
> >
> > I find it a bit weird that the user needs to provide dma information and
> > structure ! this is supposed to be completely hidden by the driver to
> > simplify user space, the driver handles dma and access to HW, user space
> > just provides the commands and payloads and driver carries the input/output
> > for that user space.
>
> This is so because our FW commands require optional DMA-able buffers.
> The application is only giving us the information that the driver
> should encapsulate in additional DMA-able buffers.
> There is a defined format for exchange of this information, because
> every command has a different number of additional buffers. Also the
> majority of the commands don't need any additional buffers.
> I hope this answers your next comments also.
>
> >
> > Also setting up a large enough DMA buffer only initially on uctx open could
> > be beneficial in your case and align better with fwctl usecases.
> >
>
> <-->
>
> > >+/**
> > >+ * struct fwctl_rpc_bnxt - describe the fwctl message for bnxt
> > >+ * @req: FW (HWRM) command input structure
> > >+ * @req_len: length of @req
> > >+ * @timeout: if the user wants to override the driver's default, 0 otherwise
> >
> > What unit ? Also there is a define in the driver (TIMOUT=500); not clear
> > what unit.
>
> Its milliseconds. I can update.

Saeed, if you are satisfied with my replies, can I make this comment
update as a fix later?
If that is fine, I wish that this series be pulled in. (this email is
on v3. There is v4)
The complete ulp callbacks cleanup, which are more roce driver
centric, will be posted as a separate series as I explained in the
other email.


>
> >
> > >+ * @num_dma: number of DMA buffers to be added to @req
> > >+ * @payload: DMA buffer details in struct fwctl_dma_info_bnxt format
> > >+ */
> >
> > if payload is a well known format, why not inline ? or why not combine req
> > and payload into one buffer and let the kernel handle the rest. Just not
> > sure how you HW interface works, so maybe once you explain the previous
> > comment this would make some sense ?
> >

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5469 bytes)