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

[Kai-Heng Feng]

> On Sep 27, 2019, at 03:20, Seth Forshee <seth.forshee at canonical.com> wrote:
> 
> 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.

Realtek finally replied to us.

> 
> 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.

We even switched the driver for Realtek 8822BE WiFi from rtlwifi.ko to rtw88.ko during previous SRU cycle.

> 
> 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).

Realtek confirmed they tested against on all hardware the rtw88 driver supports.

> 
> 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? 

Yes, they are going to do that and I'll backport the driver when needed.

> 
> 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.

Yes, all of them will be upstreamed. Realtek expects everything lands to 5.6 or 5.7. It takes time because linux-wireless are congested so not everyone can respond immediately.

It's hard to say the difficulty to backport future patches to 5.4, it largely depends on if there's another round of major net/mac80211 refactoring.
What I can say is that I'll try my best to keep everything in line.

> 
> 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.

Realtek WiFi modules are mostly used in budget devices, and many of them still use spinning rust or eMMC.
So recompiling DKMS can be a painful experience and I really hope we can avoid that.

Kai-Heng

> 
> Thanks,
> Seth