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