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