linux-kernel - 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] [day] [month] [year] [list]

Message-ID: <e2e330e5-82b8-4840-8506-b6bc2a58eda6@linux.dev>
Date: Wed, 25 Jun 2025 11:24:03 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Vikas Gupta <vikas.gupta@...adcom.com>
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

On 25/06/2025 10:29, Vikas Gupta wrote:
> 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.

I got it, my point was not in integrating it into BNXT, I totally agree
that it's more practical to have separate drivers for different
generations.

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

I was thinking of maybe creating a library with shared functions. But if
you say that data structures will change, I'm ok to have them
separately. Just be sure not to keep hacks for the really old HW.

Thanks,
Vadim

> 
> Thanks,
> Vikas