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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature