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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHLZf_uQyVUA2BrRNMRx99zOWqsFZppNKi7_h_JvKezEqFwOHQ@mail.gmail.com>
Date: Tue, 24 Jun 2025 15:53:03 +0530
From: Vikas Gupta <vikas.gupta@...adcom.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org, 
	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

Hi Vadim,

On Thu, Jun 19, 2025 at 6:13 PM Vadim Fedorenko
<vadim.fedorenko@...ux.dev> wrote:
>
> 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...

 Both the bnxt and bnge drivers follow the same protocol to send the
requests with the firmware,
so the HWRM mechanism is similar. I'll consider renaming the function
names in v2.

>
>
>

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