lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C6B4FA3D-A590-47F1-9F94-916862DD15CD@canonical.com>
Date:   Thu, 16 May 2019 01:40:00 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        Larry Finger <Larry.Finger@...inger.net>
Subject: Re: [PATCH] staging: Add rtl8821ce PCIe WiFi driver

at 00:39, Greg KH <gregkh@...uxfoundation.org> wrote:

> On Wed, May 15, 2019 at 09:06:44PM +0800, Kai-Heng Feng wrote:
>> at 20:33, Greg KH <gregkh@...uxfoundation.org> wrote:
>>
>>> On Wed, May 15, 2019 at 07:54:58PM +0800, Kai-Heng Feng wrote:
>>>> at 19:40, Greg KH <gregkh@...uxfoundation.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
>>>>>> later.
>>>>>
>>>>> Where is that driver, and why is it going to take so long to get  
>>>>> merged?
>>>>
>>>> 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
> patch?
>
>>>>>> 296 files changed, 206166 insertions(+)
>>>>>
>>>>> Ugh, why do we keep having to add the whole mess for every single one  
>>>>> of
>>>>> 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  
>> driver,
>> 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  
>> many
>> 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  
upstream :(

So basically I can’t answer any of your questions. As Larry suggested,  
their driver should be hosted separately and maybe by downstream distro.

Kai-Heng

>
> thanks,
>
> greg k-h


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ