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: <CALs4sv2PEdE6VNNi+xOXOaFP13WaYX_F3qeN9vJYz=buTN37ag@mail.gmail.com>
Date: Thu, 5 Feb 2026 09:55:08 +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

>
> 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.

>
> >+ * @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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ