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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ