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

[Vadim Fedorenko]

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