On 7/21/21 2:49 AM, Phillip Potter wrote:
Dear Larry, Whilst I (and no doubt others) are happy to look into what you've suggested, I do have a few questions: (1) Why is the version from github not the one in staging? (2) On a related note, working on it offline is difficult in terms of proving contributions, particularly for a kernel mentee such as myself. Might I suggest replacing this driver with the one you suggested entirely, so work on it can continue in public? I am happy to submit this and continue work if you think it would be viable. Many thanks and I appreciate your thoughts on this.
The reason that the newer driver is at GitHub, rather than in the kernel, is that I never want to devote the 6 months needed to get it into the shape of the old one that I did send to staging. If you take a little time to look at the GitHub code, you will see what I mean. I did this once before only to have Realtek release a new version with all the old warts again. At least we have the fact that this is a heritage product, and Realtek will not be releasing any newer drivers.
As is, the code generates very few sparse warnings, but it still contains a number of local CONFIG variables that would never be accepted in the kernel. It also contains a large number of module parameters that need to be evaluated and likely removed.
If you wish, I will give you write access to the GitHub repo so that you can make changes there. The numerous users will give you instant feedback if/when you break something. If you want to use it to replace the kernel version, go ahead. I promise that I will not give negative reviews, but I am sure others will have such comments. In any case, I will continue to maintain my repo. There are too many users with old kernels, and the backports project is difficult to use for their level of expertise.
Larry