Re: Question about patches to bnxt_en driver in buster
Hi Andy,
On Wed, Dec 01, 2021 at 09:53:46AM -0500, Andy Gospodarek wrote:
>
> [top-post]
>
> Adding debian-kernel@lists.debian.org in the event that my first message
> unintentionally made it to dust-bin. :)
>
> On Mon, Nov 22, 2021 at 04:09:00PM -0500, Andy Gospodarek wrote:
> >
> > Salvatore,
> >
> > Hello! I do not think we have met before, but I'm currently working
> > with Michael Chan et al at Broadcom on drivers for our network cards and
> > wanted to write to ask a quick question or two regarding adding a
> > feature to the Buster (4.19-based) kernel.
> >
> > Broadcom submitted ~20 patches to 4.20 that added support for a new
> > family of 100G adapters (Thor/575xx) to the bnx_en driver. Along with a few
> > bugfixes we expect that as many as 30 patches would need to be added to Buster
> > to have full support for Thor (including bugfixes).
> >
> > I noticed that there are more than this many patches to the ena driver
> > already included in the buster kernel. This makes it feel like this
> > request is not out of scope for Buster. The questions are:
> >
> > 1. Am I correct that adding new hardware support in this manner would
> > not be too much for Buster?
The short answer to this is "it depends". Generally adding Hardware
support is one of the measures we would allow as well in stable
releases. But we more aggresively now try to follow closely the
respective stable series, that is for buster 4.19.y, which we
regularly rebase. If it is likely to conflict too much hindering
proper and fast following rebases with the 4.19.y stable series then
the best option for users would be rather using backports.
> > 2. Would you prefer if we did the backport, or would it be better if we
> > provided a list of the upstream commit IDs and the kernel team would
> > want to backport? We would also want to test this, so we are happy to perform
> > and test the backport.
This goes hand in hand with the above part. You can as well provide
the patchset.
> > 3. Shall we file a bug at bugs.debian.org when are are ready or are there
> > better ways to submit a feature request?
Filling a bug for requesting would in any case be welcome for the
tracking part, but the contribution/proposal can then be directly as
well as merge request via https://salsa.debian.org/kernel-team/linux
project. An accompaning Debian bug report can make us tracking it with
an appropriate Closes marker.
Hope this helps!
Regards,
Salvatore
Reply to: