Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #73876 > unrolled thread

Re: Question about patches to bnxt_en driver in buster

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about patches to bnxt_en driver in buster Andy Gospodarek <andrew.gospodarek@broadcom.com> - 2021-12-01 16:00 +0100
    Re: Question about patches to bnxt_en driver in buster Salvatore Bonaccorso <carnil@debian.org> - 2021-12-02 13:40 +0100
      Re: Question about patches to bnxt_en driver in buster Andy Gospodarek <andrew.gospodarek@broadcom.com> - 2021-12-03 15:10 +0100

#73876 — Re: Question about patches to bnxt_en driver in buster

[Multipart message — attachments visible in raw view] — view raw

[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?
> 
> 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.
> 
> 3.  Shall we file a bug at bugs.debian.org when are are ready or are there
> better ways to submit a feature request?
> 
> Thanks for the time.
> 
> Take care,
> 
> -andy
> 

[toc] | [next] | [standalone]

#73879

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

[toc] | [prev] | [next] | [standalone]

#73885

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 02, 2021 at 01:35:39PM +0100, Salvatore Bonaccorso wrote:
> 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.

I totally understand both aspects of this.  My expectation is that the
answer would be along these lines as (1) I understand you do not want to
disrupt the normal process of pulling from linux-stable and (2) it's not
always clear how acceptable something will be until you see what it is.

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

Yes, this is really helpful.  Thank you.

We can do the backport and submit a pull-request via the Debian GitLab
instance.  This is nice as we can use all of the standard tools to
submit this for maintainers' review.

Take care,

-andy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web