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

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

Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached)

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

Contents

  Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached) Pete Batard <pete@akeo.ie> - 2020-02-03 20:10 +0100
    Bug#950578: (no subject) Pete Batard <pete@akeo.ie> - 2020-02-14 17:40 +0100
      Bug#950578: Updated patch Pete Batard <pete@akeo.ie> - 2020-02-25 12:40 +0100
        Bug#950578: (no subject) Pete Batard <pete@akeo.ie> - 2020-03-03 18:40 +0100
    Bug#950578: marked as done (linux-image-4.19.67-2-arm64: Add ACPI  network interface support for RPi4 (patch attached)) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-03-30 10:20 +0200
    Bug#950578: fixed in linux 5.5.13-1 Pete Batard <pete@akeo.ie> - 2020-03-30 10:50 +0200
      Bug#950578: fixed in linux 5.5.13-1 Ben Hutchings <benh@debian.org> - 2020-03-30 15:40 +0200
    Bug#950578: linux-image-5.5.0-1-armmp: enable Raspberry Pi 4 NIC module "bcmgenet" Steven Shiau <steven@nchc.org.tw> - 2020-04-06 10:30 +0200
    Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded Steven Shiau <steven@nchc.org.tw> - 2020-04-09 05:50 +0200
      Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded Ben Hutchings <ben@decadent.org.uk> - 2020-04-13 16:40 +0200
    Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 Pete Batard <pete@akeo.ie> - 2020-05-07 12:20 +0200
      Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 Ben Hutchings <benh@debian.org> - 2020-05-07 14:50 +0200
        Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 Pete Batard <pete@akeo.ie> - 2020-05-07 15:30 +0200
          Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 Ben Hutchings <benh@debian.org> - 2020-05-09 23:30 +0200
            Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 Pete Batard <pete@akeo.ie> - 2020-05-10 00:40 +0200
            Difficulties with kernel package contributions Ben Hutchings <ben@decadent.org.uk> - 2020-05-17 18:00 +0200

#66296 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached)

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

Package: src:linux
Version: 4.19.67-2
Severity: important
Tags: patch


Dear Maintainers,

While it is currently possible to boot and install Debian 10.x on the 
Raspberry Pi 4 using the official vanilla ARM64 ISO images (through the 
use of the latest EDK2 RPi4 firmware such as the one provided at [1]), 
one of the major drawbacks that exists is that, because the EDK2 
firmware currently only supports Linux boot in ACPI mode and also 
because the native Debian kernel does not include the bcmgenet module at 
all (module is currently disabled altogether), it is not possible to 
perform a networked installation of Debian on the Raspberry Pi 4.

Due to the popularity of the platform, we therefore suggest that 
bcmgenet should be enabled for the next Debian ARM64 10.x release as a 
matter of priority, after the the attached patch has been applied to the 
default kernel as some modifications are required for the network 
interface to work in ACPI mode in coordination with the EDK2 firmware.

With bcmgenet is currently being disabled as a module, and with the 
effort we made to ensure that the modifications applied have the least 
impact possible on existing code (the existing Device Tree code paths 
are left virtually untouched), we assert that the inclusion of this 
patch should be low risk and therefore very desirable to have for the 
potentially large number of RPi4 users, who should then be able to 
perform netinst installation of Debian 10.x on their platform using the 
vanilla ARM64 images.

Thanks and regards,

/Pete

[1] https://github.com/pftf/RPi4

-- System Information:
Debian Release: 10.2
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.87 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#66368 — Bug#950578: (no subject)

Just gonna add that the latest UEFI Firmware, released today at 
https://github.com/pftf/RPi4/releases, now contains all the elements 
needed (ACPI binding and UMAC initialization) for the above patch to work.

Which means that, the only limiting factor for UEFI Debian 10.x netinst 
on a Raspberry Pi 4 is that the kernel is missing the patch above.

Thanks,

/Pete

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

#66416 — Bug#950578: Updated patch

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

Here's an updated version of the patch, since we switched to using 
"rgmii-rxid" instead of "rgmii" for phy-mode in ACPI (which is what the 
current Linux Device Tree also uses and which prevents packet loss and 
network instability) and the 4.19 bcmmii driver is missing a case for 
PHY_INTERFACE_MODE_RGMII_RXID.

We also use this opportunity to fix a possible warning in 
bcmgenet_mii_acpi_init().

Once again, it would be greatly appreciated if this patch could be 
applied as a matter of priority as it's all that stands between making 
the next release of Debian net installable on a Raspberry Pi 4.

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

#66447 — Bug#950578: (no subject)

Just going to point out that the 5.x equivalent patch has now been 
applied to Linux mainline as per:

https://lkml.kernel.org/lkml/20200224.153146.125327154283545636.davem@davemloft.net/

Could we get some acknowledgement that this patchset is being looked at 
for possible integration and isn't falling through the cracks?

This has been opened for more than a month now, and, notwithstanding the 
patch update above, it's quite damaging for Raspberry Pi users that the 
10.3 update didn't include these changes, as it would have enabled them 
to install Debian from the vanilla 10.3 release ISO whereas Pi 4 users 
will have to wait months before that happens...

So, can someone please look at this request and at least acknowledge it?

Thank you,

/Pete

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

#66643 — Bug#950578: marked as done (linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached))

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

Your message dated Mon, 30 Mar 2020 08:10:09 +0000
with message-id <E1jIpUn-000G6x-77@fasolo.debian.org>
and subject line Bug#950578: fixed in linux 5.5.13-1
has caused the Debian Bug report #950578,
regarding linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4 (patch attached)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
950578: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950578
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

#66649 — Bug#950578: fixed in linux 5.5.13-1

Does that mean that the next Debian ISO installer will use Linux kernel 
5.5.13.1 or later?

Because, if that is not the case, this bug is certainly not fixed at all 
and must be reopened.

To reiterate, the problem is that the official netinst ISO cannot 
perform a network installation of the Debian packages due to its use of 
a 4.x kernel that is lacking an ACPI compatible Genet driver.

This means that the *installation* 4.x kernel (i.e. the default kernel 
used by the installer, which, unlike the post installation kernel, is 
not something that can be upgraded) must be patched with a retrofitted 
Genet driver.

In other words, if this is considered fixed simply because the 
additional Debian kernel package has been updated to latest mainline, 
then this is *NOT* fixed at all, as the one and original problem of not 
being able to perform a networked installation of Debian on a Raspberry 
Pi 4 will remain.

I would therefore appreciate if you can please answer the following:

Will the next release of Debian ditch 4.19 kernels altogether and switch 
to the 5.5.13-1 (or later) kernel for its installer?

Only if the answer to the question above is "yes" can the issue be 
considered fixed.

But if the answer is no, then you must reopen this issue and apply the 
proposed fix, as the 5.5.13.1 update will not address this issue at all.

Thank you,

/Pete

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

#66656 — Bug#950578: fixed in linux 5.5.13-1

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

On Mon, 2020-03-30 at 09:44 +0100, Pete Batard wrote:
> Does that mean that the next Debian ISO installer will use Linux kernel 
> 5.5.13.1 or later?
> 
> Because, if that is not the case, this bug is certainly not fixed at all 
> and must be reopened.
> 
> To reiterate, the problem is that the official netinst ISO cannot 
> perform a network installation of the Debian packages due to its use of 
> a 4.x kernel that is lacking an ACPI compatible Genet driver.
> 
> This means that the *installation* 4.x kernel (i.e. the default kernel 
> used by the installer, which, unlike the post installation kernel, is 
> not something that can be upgraded) must be patched with a retrofitted 
> Genet driver.
[...]

This is why the bug tracking system records which versions are fixed,
and which are not.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

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

#66690 — Bug#950578: linux-image-5.5.0-1-armmp: enable Raspberry Pi 4 NIC module "bcmgenet"

Package: src:linux
Version: 5.5.13-2
Severity: normal

Dear Maintainer,
Since the module for the NIC of raspberry Pi 4 was enabled in Linux 5.5.13-2 arm64:

$ grep CONFIG_BCMGENET config-5.5.0-1-arm64
CONFIG_BCMGENET=m

However, it's not enabled in armhf:

$ grep CONFIG_BCMGENET config-5.5.0-1-armmp-lpae
# CONFIG_BCMGENET is not set

Is that possible you can enable it for armhf architecture in the next 
release?
Some people still would like to use armhf for raspberry Pi 4.

Thank you very much.

Steven

-- 
Steven Shiau <steven _at_ stevenshiau org>
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

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

#66721 — Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded

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

Package: src:linux
Version: 5.5.13-2
Severity: normal

Dear Maintainer,

I created an arm64 live system for Raspberry Pi 4 using Debian 
live-build, and it successfully booted into the initramfs.
However, after the network module bcmgenet was loaded, I got the kernel 
panic.
Attached please find the output messages on the serial console.
If you need more info or tests, please let me know.

Thank you very much.

Steven

-- 
Steven Shiau <steven _at_ stevenshiau org>
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

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

#66745 — Bug#950578: Linux 5.5.0-1-arm64: kernel panic after module bcmgenet was loaded

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

On Thu, 2020-04-09 at 11:43 +0800, Steven Shiau wrote:
> Package: src:linux
> Version: 5.5.13-2
> Severity: normal
> 
> Dear Maintainer,
> 
> I created an arm64 live system for Raspberry Pi 4 using Debian 
> live-build, and it successfully booted into the initramfs.
> However, after the network module bcmgenet was loaded, I got the kernel 
> panic.
> Attached please find the output messages on the serial console.

That's a WARNING not a panic.  And this needs to be a separate bug
report.

> If you need more info or tests, please let me know.

I don't see any sign of UEFI in the kernel log.  I think our kernel
only supports the RPi 4 running UEFI firmware.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

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

#67021 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

I would really like to get an update on this, because I really can't 
understand what the holdup is, or why non related issues seem to be be 
shoved into this bug, with the apparent end result of completely 
distracting from the matter at hand.

This bug is about one thing and one thing only: Enabling Raspberry Pi 4 
users to perform a netinstall using the next official aarch64 ISO of 
Debian 10.x. Therefore it is only about backporting the Genet ACPI 
driver into the 4.19 kernel, for which an effective backport patch was 
actually submitted.

It is *NOT* about tracking whether the 5.x kernel packages have Genet 
support. And it is *NOT* about troubleshooting network issues with the 
5.x kernel.

The sole focus for the bug, as it was opened by the submitter (myself) 
is to add Genet support to the kernel that is used by the Debian ISO 
installer, and, seeing that no progress appears to have been made on 
that front, despite the fact that a patch to *SOLVE* the reported issue 
has been submitted along with the bug report, I would greatly appreciate 
if we could reframe the problem and drop all references to 5.x genet 
support as being linked to this bug, as it looks to me like this is 
hindering the resolution of the one and only issue that prompted the 
creation of this bug.

I would also greatly appreciate if this could actually be treated with 
the level of urgency it requires on account of the following.

- As of March 2020, the Raspberry Pi Foundation announced that it had 
sold 640 000 Raspberry Pi 4 units, and one can reasonably expect that 1 
million units will have been sold by year's end, which clearly makes the 
platform one of the most popular ARM64 targets, if not the most popular, 
and therefore, one can reasonably expect many of its users to want to 
install Debian 10.x on it. By not applying the proposed patch and 
enabling netinst from official Debian 10.x ISOs as a matter of urgency, 
Debian maintainers will be doing a major disservice to their users.

- The required patch to *SOLVE* the issue has been provided, so it's not 
like Debian maintainers have to invest time to create the backport 
themselves. And for the record, I did work with Jeremy Linton, the 
person who upstreamed the main patch for 5.x kernels, and used the code 
that he was in the process of submitting at that time to create the 
backport (which is actually tailored for easy review by Debian 
maintainers), so the attached patch was not produced in isolation.

- Though it may look that way at first glance, this patch is not being 
requested because we are using a custom/toy bootloader. On the contrary, 
the very reason why we can use the official aarch64 ISO is because we 
are following industry standards pretty much to the letter. We are using 
both ACPI and UEFI in a very official manner, and as a matter of fact, 
the UEFI firmware that is meant to be used with the official ISOs is 
fully integrated with the EDK2 [1]. So this is not a "it would be nice 
if Debian could do this so that it would work with our custom 
bootloader" but really a "If Debian is to follow industry standards for 
the Raspberry Pi 4 and other UEFI platforms that use a Broadcom Genet 
NIC, then it should provide the functionality requested above, for which 
we have conveniently provided a patch".

So, if the integration of the proposed patch into the kernel used by the 
next Debian ISO release is going to be delayed further, I would really 
like the Debian maintainers to explain why that is the case.

We have been *EXCEEDINGLY* patient about this and waited in the hope 
that Debian maintainers would understand the urgency, but, seeing that 
Debian 10.4, which is planned to be released in 2 days, does not appear 
to integrate the patch we proposed (either that or this bug tracker was 
not updated as it should), I feel that we might as well tell the 
thousands of Raspberry Pi 4 users who we are seeing downloading the UEFI 
firmware in the hope of using it to install GNU/Linux, that they should 
just forget about Debian, because it seems Debian maintainers have 
either very little interest in ensuring that their OS can be installed 
on what is, by far, be the most popular ARM64 platforms out there, or 
have failed to grasp the implications of not applying the patch that can 
solve this very important issue and which was proposed *MONTHS* ago...

Regards,

/Pete

[1] 
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi4

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

#67023 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

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

Pete Batard wrote:
> I would really like to get an update on this, because I really can't 
> understand what the holdup is, or why non related issues seem to be be 
> shoved into this bug, with the apparent end result of completely 
> distracting from the matter at hand.
[...]
> It is *NOT* about tracking whether the 5.x kernel packages have Genet 
> support. And it is *NOT* about troubleshooting network issues with the 
> 5.x kernel.

The Debian bug tracking system is quite capable of recording *which*
versions an issue is found and fixed in.  So it's fine that this bug is
marked fixed in 5.x; we still know that it's unfixed in 4.19.

Also, there would be no point in enabling this driver in 4.19, only to
have people find on upgrade to the next version on Debian that we
didn't enable it there.  That's why we're concerned with both versions.

[...]
> I would also greatly appreciate if this could actually be treated with 
> the level of urgency it requires on account of the following.

All "missing hardware support" bugs have severity "important".

[...]
> - The required patch to *SOLVE* the issue has been provided, so it's not 
[...]

I acknowledge that you have provided a patch, which I appreciate, and
I'm sorry you haven't had a specific response to that yet.

Generally we want patches that correspond closely to upstream commits. 
For 5.5 I had to backport these 6 commits:

ce69e2162f15 mdio_bus: Add generic mdio_find_bus()
480ded265205 net: bcmgenet: refactor phy mode configuration
6ef31c8bee5b net: bcmgenet: enable automatic phy discovery
99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support
26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter
ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings

Can you please provide separate backports of these, instead of a single
patch where it's hard to see what changed?

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

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

#67024 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

On 2020.05.07 13:45, Ben Hutchings wrote:
> Also, there would be no point in enabling this driver in 4.19, only to
> have people find on upgrade to the next version on Debian that we
> didn't enable it there.  That's why we're concerned with both versions.

Yes, I did consider that, but I feel that this is an issue that should 
have been tracked separately (especially as, like we have seen, this 
polluted this issue with unrelated queries), as it doesn't have the same 
level of severity. Vanilla breakage vs optional breakage should not be 
grouped together IMO. But of course, you're free to do what you want.

> [...]
>> I would also greatly appreciate if this could actually be treated with
>> the level of urgency it requires on account of the following.
> 
> All "missing hardware support" bugs have severity "important".

And I will assert that bugs should be evaluated in terms of potential 
users that are going to be impacted.

Support for a NIC that's used in niche hardware should not have the same 
level of severity as support for a NIC that is used on hardware that 
sold a quarter of a million units in less than a year.

> [...]
>> - The required patch to *SOLVE* the issue has been provided, so it's not
> [...]
> 
> I acknowledge that you have provided a patch, which I appreciate, and
> I'm sorry you haven't had a specific response to that yet.
> 
> Generally we want patches that correspond closely to upstream commits.
> For 5.5 I had to backport these 6 commits:
> 
> ce69e2162f15 mdio_bus: Add generic mdio_find_bus()
> 480ded265205 net: bcmgenet: refactor phy mode configuration
> 6ef31c8bee5b net: bcmgenet: enable automatic phy discovery
> 99c6b06a37d4 net: bcmgenet: Initial bcmgenet ACPI support
> 26bd9cc64faf net: bcmgenet: Fetch MAC address from the adapter
> ae200c26b32b net: bcmgenet: reduce severity of missing clock warnings
> 
> Can you please provide separate backports of these, instead of a single
> patch where it's hard to see what changed?

Sigh.

I specifically designed the patch I submitted for easy review and 
integration, because there are missing elements from 4.x that are 
present in 5.x, that we have to compensate for. I would rather not have 
to split it, especially as I believe it should be included as a matter 
of priority and we're simply adding delays.

If Debian 11 was planning to continue to use a 4.x kernel, I could see 
some point in splitting the patch and ensuring, so that it *might* be 
easier to maintain for many years to come. But, from what I gather, 
Debian 11 will bump kernel major, so any work being done making the 4.x 
backport (which is not that complex, sorry, especially as I made sure to 
already group the code changes in a manner that makes it easier to 
handle) easier to maintain in the long run seems like a waste of time, 
even if 10.x may see long time support for a few more years...

If you had made that point a few months ago, I would have been more 
inclined to do it, but at this stage, considering that it's too late for 
10.4 anyway, and considering that I feel like I've wasted more than 
enough time trying to push for this change to be included to help RPi4 
Debian users, and that 2 releases have gone by without any progress, I 
will respectfully decline to provide alterations to the submission 
unless it has to do with something that effectively prevents its 
integration, sorry.

Regards,

/Pete

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

#67033 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

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

On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote:
[...]
> I specifically designed the patch I submitted for easy review and 
> integration, because there are missing elements from 4.x that are 
> present in 5.x, that we have to compensate for. I would rather not have 
> to split it, especially as I believe it should be included as a matter 
> of priority and we're simply adding delays.

I personally find it much easier to review backports in this form, and
it is the usual practice in Debian to backport changes in this form
where possible.

> If Debian 11 was planning to continue to use a 4.x kernel, I could see 
> some point in splitting the patch and ensuring, so that it *might* be 
> easier to maintain for many years to come.  But, from what I gather, 
> Debian 11 will bump kernel major, so any work being done making the 4.x 
> backport (which is not that complex, sorry, especially as I made sure to 
> already group the code changes in a manner that makes it easier to 
> handle) easier to maintain in the long run seems like a waste of time, 
> even if 10.x may see long time support for a few more years...
[...]

Debian 10 will be supported for 4 more years, in fact.  During that
time this driver may well see other changes backported through the
stable process.  Based on past experience, I think it will be easier to
resolve any conflicts if our patches make smaller changes.

So please don't assume what's "easier to handle" for us.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

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

#67034 — Bug#950578: linux-image-4.19.67-2-arm64: Add ACPI network interface support for RPi4

On 2020.05.09 22:20, Ben Hutchings wrote:
> On Thu, 2020-05-07 at 14:23 +0100, Pete Batard wrote:
> [...]
>> I specifically designed the patch I submitted for easy review and
>> integration, because there are missing elements from 4.x that are
>> present in 5.x, that we have to compensate for. I would rather not have
>> to split it, especially as I believe it should be included as a matter
>> of priority and we're simply adding delays.
> 
> I personally find it much easier to review backports in this form, and
> it is the usual practice in Debian to backport changes in this form
> where possible.

Then you should have asked for that 3 months ago.

Sorry but that mistakes of not following up on the patch I submitted in 
a reasonable timeframe, or understanding its context and priority level 
is entirely on you.

I have tried all the means I knew to bring attention to this patch for 
weeks that followed its submission (including posting about it in 
various Debian mailing lists, including arm64 and debian-release), and 
nothing happened, and especially nobody provided any inkling about the 
submission needing to be split, so you genuinely have exhausted all of 
the good will I had on that topic.

Moreover, if you are taking my refusal to split the patch as an excuse 
not to produce your own effort to include it in the next release, then 
you are simply corroborating the idea I have established that Debian 
appears to have no clue about the level of importance it should actually 
allocate to the underlying problem this is attempting to solve, and, 
furthermore, that it may simply be looking for a way out of a situation 
it mishandled.

In other words, I am waiting to see a real concerted effort on your side 
before I decide whether I am willing to contribute any further, and 
insistance on asking me to perform work that, if you understood the 
actual severity of the situation, you should be more than willing to 
perform yourself as a matter of urgency, simply indicates that you still 
haven't understood the nature of the underlying situation. As a direct 
result of that, I have good reasons to estimate that further involvement 
from my side is simply not worth the trouble, because it appears that 
you are still going to be bouncing, delaying or mishandling the ability 
for RPi4 users to install Debian from vanilla Debian ISOs.

Therefore either you understand the importance of the problem, and are 
willing to perform the work required to reorganize the submission 
according to your *preferences*. Or you continue to hint that you don't, 
and instead try to place the blame on someone from whom you have long 
exhausted any willingness to contribute to something they have good 
reasons to believe, from the continued unwillingness to take the 
necessary actions on your side, is most likely going to amount to 
*another* completely wasted effort.

In other words, I will need to see some real good will from Debian in 
the matter of trying to salvage the current RPi4 situation before I 
decide to get involved in trying to contribute again. Thus, in case this 
was not clear, let me be explicit in saying that you are not going to 
see any further contribution from me until you have made some visible 
effort to remedy that.

Regards,

/Pete

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

#67108 — Difficulties with kernel package contributions

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

I'm not cc'ing the BTS on this as this discussion is no longer specific
to one bug report.

On Sun, 10 May 2020 16:46:47 +0000 Mark Pearson <mpearson@lenovo.com> wrote:
[...]
> I'm hesitant to post to this thread as I don't agree with all of Pete's points,
> but this thread somewhat resonated, especially this last comment.
> As someone who is still learning and finding their way through the process 
> myself - finding the preferred way of doing things and all the little details  
> is hard - or at least that's my experience. The kernel handbook is OK, but 
> it doesn't cover this detail in my opinion

Yes, there's definitely room for improvement in the documentation.

We also have documentation spread across debian/README.source, kernel-
handbook, the docs directory of kernel-team.git, and some wiki pages. 
We (the kernel team) should clarify who they're for and what
information belongs where; and probably we should add more cross-
references.

Oh, and I gave this talk:

https://peertube.debian.social/videos/watch/3b1818f2-e44c-4cbd-b9a0-c9465c53667a
https://www.decadent.org.uk/ben/talks/mdch2018-help-the-kernel-team.pdf

and I'm not sure all of the information there is written down elsewhere...

> It would be really nice to have an idiots/beginners guide to what the best way
> is to make the maintainers life easy - I have been stumbling my way through, 
> making plenty of mistakes and I'm sure I generate more headaches then I mean 
> to. 

I got the impression that you're not hugely familiar with git, so
having to deal with git and quilt at the same time is bound to be
difficult.

> Having a guide explaining how to backport a patch cleanly from kernel.org 
> would be a really nice thing to have - down to best working practices with 
> salsa, all the bits of info that have to be added to the patch(es), using dch, 
> how to deal with patches that don't merge cleanly, git best practices etc.

A fair amount of that is needed for Debian packages in general, so I
don't think we should be writing our own documentation about it but we
should refer to existing documentation.

> I'm 
> sure as a kernel maintainer you see the same mistake again and again and it
> must be infuriating. Recommended workflows would be amazing - I'm still not
> sure what the *best* way to work on the Debian kernel is (I have steps I use 
> but I had to figure them out myself and I suspect they could be better).

I'm going to assume that you're talking specifically about backporting
features from upstream (either mainline or a maintainer tree).  If the
target Debian branch is not far behind, that I would usually:

1. Export the upstream commits with git-format-patch-for-debian.  This is a
   wrapper for "git format-patch" that adds the extra patch headers, and it's
   in the kernel-team.git repository.
2. Depending on the number of patches, either:
   - Import them individually, with something like:
         quilt import -P features/all/foo.patch ~/linux/0001-foo.patch
   - Move them into a subdirectory of debian/patches, e.g.:
         cd debian/patches
         mkdir features/all/foo
         mv ~/linux/0*.patch features/all/foo/
         ls features/all/foo/*.patch >> series
3. Apply each patch (quilt push) and fix up any conflicts.
4. Build and test (to the extent possible).

If the target Debian branch is further behind (e.g. 4.19 as Pete is
dealing with) then I would more likely:

1. Start a git branch from the upstream stable branch.
2. For each upstream commit:
   1. Cherry-pick it with "git cherry-pick -x" it.  Fix up any
      conflicts and note the change in the commit message.
   2. Build the kernel, or at least the affected subsystem or driver.
      Fix any failure, possibly by picking additional commits it
      depends on.  Note any changes in the commit message.
3. Export the backported commits and import into the Debian package as
   in the previous list.  (This requires fixing up the Origin headers,
   and I don't currently have an easy way to do that.)

> It would also be really nice to have a way to reasonably escalate things (with
> a reason for the escalation) without pissing off people who are too busy to be 
> swamped with nag-emails (I've been told those are a huge no-no with the 
> kernel Debian community). I'd be OK with a "this is not a priority I will look at it 
> in N weeks" but having no insight into where you are in the queue or if you
> have been missed is hard.

Speaking just for myself, I don't have a queue of work.  I look at bug
reports as they come in, and triage them (adjust severity, reassign,
close if invalid).  I also make a note of those that appear to be
immediately actionable (request applying a patch from upstream, or
request a config change), and I deal with those in batches.

I will take longer to answer bug reports that look like they require
more time to investigate or review.  And unfortunately, with the
current size and availability of the team, there are just too many bugs
to answer all of them.

> From my point of view I regularly get asked "when will X be available in Debian" 
> and I can never give an estimate. I cannot recommend to even expert Lenovo 
> customers to use Debian on our platforms - and that is frustrating because it is 
> a great distro.

It's also a bit disappointing for me, as someone who's used Debian on a
succession of Thinkpads for 13 years.

> Please note - I do not mean to sound like I am complaining. I believe part of 
> being in the community is to do things the way the community wants. I just 
> think the path for newcomers to contribute and make Debian better is not 
> an easy one

I agree.

> and wanted to offer insight as to why. If you can point me at 
> what I'm missing that would be awesome (and slightly embarrassing as I've
> looked for it at length)

No need to be embarrassed.  If my answers above don't help, let me know
what specifically what information you're missing.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky

[toc] | [prev] | [standalone]

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

csiph-web