[SRU] [D/E/Unstable] [Pull] Enable Realtek Wireless Lan 8723DE

[Seth Forshee]

On Thu, Sep 05, 2019 at 02:05:47AM +0800, Kai-Heng Feng wrote:
> BugLink: https://bugs.launchpad.net/bugs/1780590
> 
> [Impact]
> There's no in-kernel support for Realtek 8723DE, so users need to use
> out-of-tree DKMS which is not from Ubuntu archive. This has security
> implication and should be avoided. Also this provides pretty bad user
> experience.
> 
> [Fix]
> Add support to Realtek 8723DE.
> All commits are cherry-picked from Realtek maintained repo:
> https://github.com/rtlwifi-linux/rtw88_8723de
> 
> [Test]
> With the patch series applied, 8723DE can scan and connect to APs
> succesfully. Also did some S3 smoke test, it continues to work.
> 
> [Regression Potential]
> Low. The device in question was never supported, and if there's any
> regression, we can count on Realtek Wireless team, thy are now pretty
> responsive on upstream mailing list.

Sorry for the long delay in reviewing these, but it was quite a pile.

On the one hand, the changes look like upstreamable sorts of changes,
nothing obviously horrendous or anything like that. However it is a
*lot* of changes, and not just adding new hw support. There's a very
substantial amount of refactoring and enhancing the code for already
supported hw. For that reason I don't think this is SRU material.

For eoan, I'm still on the fence. I'd like to know what kind of
regression testing has been done (even if it wasn't done by you
personally, i.e. if realtek is validating the changes against supported
hardware).

The maintenance burden could also be an issue. Can we count on
assistance from you/realtek if upstream fixes to the driver conflict
with the very substantial changes made by these patches? 

And what's the story on these patches going upstream? When we start to
think about having to maintain these on top of 5.4, then we're talking
about a much longer timeframe for maintaining these patches. Will these
be going into 5.4? If not, why? If we support this in eoan there's a
presumption that we will continue to support it in FF, so I want to be
sure that we don't end up with something that's going to be extremely
difficult to maintain for the life of an LTS release.

I'm also curious why you think we shouldn't add a dkms package for this
driver instead of pulling the changes into the kernel. Granted that dkms
isn't ideal, but neither is 16,000+ lines of non-upstream changes.

Thanks,
Seth