netdev - Re: [net-next, 04/10] bng_en: Add initial interaction with firmware

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_svEKdeQPpvXrKGt-uKXQ0Zo-d+E3UvGYzH9h6fXudpVA@mail.gmail.com>
Date: Wed, 25 Jun 2025 14:59:51 +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, 04/10] bng_en: Add initial interaction with firmware

Hi Vadim,

> >>> +     req->year = cpu_to_le16(1900 + tm.tm_year);
> >>> +     req->month = 1 + tm.tm_mon;
> >>> +     req->day = tm.tm_mday;
> >>> +     req->hour = tm.tm_hour;
> >>> +     req->minute = tm.tm_min;
> >>> +     req->second = tm.tm_sec;
> >>> +     return hwrm_req_send(bd, req);
> >>> +}
> >>
> >> This whole function looks like copy-paste from bnxt, did you consider
> >> merging these parts?
> >
> > Both the bnxt and bnge drivers follow the same protocol to send the
> > requests to  the firmware,
> > so some functions may appear similar. However, we do not plan to share
> > the code, as certain
> >   fundamental data structures will differ.
>
> But at the same time some data structures are completely the same. Why
> do you think code duplication will work better on long run?

In the long run, maintaining this driver for future hardware is more practical
for us than integrating code into the BNXT driver.
Nevertheless, we are making a concerted effort to minimize duplication
wherever feasible.
So currently, we share the HSI (bnxt_hsi.h) as the driver to firmware
protocol remains largely unchanged.
While data structures are currently identical, but not all, we
recognize this is due to the fundamental
architectural similarities between the new and previous chip generations.
Newer chip features will definitely change the data structures and
related implementations.

Does this clarify your concern?

Thanks,
Vikas

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