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
