[PATCH] staging: Add rtl8821ce PCIe WiFi driver
kai.heng.feng at canonical.com
Wed May 15 17:40:00 UTC 2019
at 00:39, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Wed, May 15, 2019 at 09:06:44PM +0800, Kai-Heng Feng wrote:
>> at 20:33, Greg KH <gregkh at linuxfoundation.org> wrote:
>>> On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote:
>>>> at 19:40, Greg KH <gregkh at linuxfoundation.org> wrote:
>>>>> On Wed, May 15, 2019 at 07:24:01PM +0800, Kai-Heng Feng wrote:
>>>>>> The rtl8821ce can be found on many HP and Lenovo laptops.
>>>>>> Users have been using out-of-tree module for a while,
>>>>>> The new Realtek WiFi driver, rtw88, will support rtl8821ce in 2020 or
>>>>> Where is that driver, and why is it going to take so long to get
>>>> rtw88 is in 5.2 now, but it doesn’t support 8821ce yet.
>>>> They plan to add the support in 2020.
>>> Who is "they" and what is needed to support this device and why wait a
>>> full year?
>> “They” refers to Realtek.
>> It’s their plan so I can’t really answer that on behalf of Realtek.
> Where did they say that? Any reason their developers are not on this
>>>>>> 296 files changed, 206166 insertions(+)
>>>>> Ugh, why do we keep having to add the whole mess for every single one
>>>>> these devices?
>>>> Because Realtek devices are unfortunately ubiquitous so the support is
>>>> better come from kernel.
>>> That's not the issue here. The issue is that we keep adding the same
>>> huge driver files to the kernel tree, over and over, with no real change
>>> at all. We have seen almost all of these files in other realtek
>>> drivers, right?
>> Yes. They use one single driver to support different SoCs, different
>> architectures and even different OSes.
> Well, they try to, it doesn't always work :(
>> That’s why it’s a mess.
> Oh we all know why this is a mess. But they have been saying for
> _years_ they would clean up this mess. So push back, I'm not going to
> take another 200k lines for a simple wifi driver, again.
> Along those lines, we should probably just delete the other old realtek
> drivers that don't seem to be going anywhere from staging as well,
> because those are just confusing people.
>>> Why not use the ones we already have?
>> It’s virtually impossible because Realtek’s mega wifi driver uses tons of
>> #ifdefs, only one chip can be selected to be supported at compile time.
> That's not what I asked.
> I want to know why they can't just add support for their new devices to
> one of the many existing realtek drivers we already have. That is the
> simpler way, and the correct way to do this. We don't do this by adding
> 200k lines, again.
>>> But better yet, why not add proper support for this hardware and not use
>>> a staging driver?
>> Realtek plans to add the support in 2020, if everything goes well.
> Device "goes well" please. And when in 2020? And why 2020? Why not
> 2022? 2024?
>> Meanwhile, many users of HP and Lenovo laptops are using out-of-tree
>> some of them are stuck to older kernels because they don’t know how to fix
>> the driver. So I strongly think having this in kernel is beneficial to
>> users, even it’s only for a year.
> So who is going to be responsible for "fixing the driver" for all new
> kernel api updates? I'm tired of seeing new developers get lost in the
> maze of yet-another realtek wifi driver. We've been putting up with
> this crud for years, and it has not gotten any better if you want to add
> another 200k lines for some unknown amount of time with the hope that a
> driver might magically show up one day.
I have no idea why they haven’t made everything upstream, and I do hope
they did a better job, so I don’t need to cleanup their driver and send it
So basically I can’t answer any of your questions. As Larry suggested,
their driver should be hosted separately and maybe by downstream distro.
> greg k-h
More information about the devel