linux-kernel - Re: [net-next, 03/10] bng_en: Add firmware communication mechanism

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6735a940-bce8-43f5-a6d7-7a48ace197c8@linux.dev>
Date: Thu, 19 Jun 2025 13:43:35 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Vikas Gupta <vikas.gupta@...adcom.com>, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 andrew+netdev@...n.ch, horms@...nel.org
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 michael.chan@...adcom.com, pavan.chebbi@...adcom.com,
 vsrama-krishna.nemani@...adcom.com,
 Bhargava Chenna Marreddy <bhargava.marreddy@...adcom.com>,
 Rajashekar Hudumula <rajashekar.hudumula@...adcom.com>
Subject: Re: [net-next, 03/10] bng_en: Add firmware communication mechanism

On 18/06/2025 15:47, Vikas Gupta wrote:
> Add support to communicate with the firmware.
> Future patches will use these functions to send the
> messages to the firmware.
> Functions support allocating request/response buffers
> to send a particular command. Each command has certain
> timeout value to which the driver waits for response from
> the firmware. In error case, commands may be either timed
> out waiting on response from the firmware or may return
> a specific error code.
> 
> Signed-off-by: Vikas Gupta <vikas.gupta@...adcom.com>
> Reviewed-by: Bhargava Chenna Marreddy <bhargava.marreddy@...adcom.com>
> Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@...adcom.com>
> ---
>   drivers/net/ethernet/broadcom/bnge/Makefile   |   3 +-
>   drivers/net/ethernet/broadcom/bnge/bnge.h     |  13 +
>   .../net/ethernet/broadcom/bnge/bnge_hwrm.c    | 503 ++++++++++++++++++
>   .../net/ethernet/broadcom/bnge/bnge_hwrm.h    | 107 ++++
>   4 files changed, 625 insertions(+), 1 deletion(-)
>   create mode 100644 drivers/net/ethernet/broadcom/bnge/bnge_hwrm.c
>   create mode 100644 drivers/net/ethernet/broadcom/bnge/bnge_hwrm.h
> 
> diff --git a/drivers/net/ethernet/broadcom/bnge/Makefile b/drivers/net/ethernet/broadcom/bnge/Makefile
> index e021a14d2fa0..b296d7de56ce 100644
> --- a/drivers/net/ethernet/broadcom/bnge/Makefile
> +++ b/drivers/net/ethernet/broadcom/bnge/Makefile
> @@ -3,4 +3,5 @@
>   obj-$(CONFIG_BNGE) += bng_en.o
>   
>   bng_en-y := bnge_core.o \
> -	    bnge_devlink.o
> +	    bnge_devlink.o \
> +	    bnge_hwrm.o
> diff --git a/drivers/net/ethernet/broadcom/bnge/bnge.h b/drivers/net/ethernet/broadcom/bnge/bnge.h
> index 19d85aabab4e..8f2a562d9ae2 100644
> --- a/drivers/net/ethernet/broadcom/bnge/bnge.h
> +++ b/drivers/net/ethernet/broadcom/bnge/bnge.h
> @@ -13,6 +13,8 @@ enum board_idx {
>   	BCM57708,
>   };
>   
> +#define INVALID_HW_RING_ID      ((u16)-1)
> +
>   struct bnge_dev {
>   	struct device	*dev;
>   	struct pci_dev	*pdev;
> @@ -22,6 +24,17 @@ struct bnge_dev {
>   	char		board_serialno[BNGE_VPD_FLD_LEN];
>   
>   	void __iomem	*bar0;
> +
> +	/* HWRM members */
> +	u16			hwrm_cmd_seq;
> +	u16			hwrm_cmd_kong_seq;
> +	struct dma_pool		*hwrm_dma_pool;
> +	struct hlist_head	hwrm_pending_list;
> +	u16			hwrm_max_req_len;
> +	u16			hwrm_max_ext_req_len;
> +	unsigned int		hwrm_cmd_timeout;
> +	unsigned int		hwrm_cmd_max_timeout;
> +	struct mutex		hwrm_cmd_lock;	/* serialize hwrm messages */
>   };

It's all looks pretty similar to what is used in bnxt driver. Why do you
duplicate the code rather then reusing (and improving) the existing one?

I didn't look carefully, but in case it's impossible to merge hwrm code
from bnxt, you have to make function names prepended with bnge prefix...