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]
Date:   Fri, 13 Oct 2023 11:24:40 -0500
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Arnd Bergmann <arnd@...db.de>,
        Philipp Hortmann <philipp.g.hortmann@...il.com>,
        Arnd Bergmann <arnd@...nel.org>, Kalle Valo <kvalo@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Claudiu Beznea <claudiu.beznea@...on.dev>,
        Jakub Kicinski <kuba@...nel.org>, Pavel Machek <pavel@....cz>,
        "David S . Miller" <davem@...emloft.net>,
        linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-staging@...ts.linux.dev
Subject: Re: [PATCH] [RFC] wireless: move obsolete drivers to staging

On 10/13/23 10:36, Arnd Bergmann wrote:
> At the moment, I'd suggest focusing on the drivers that still use wext (git grep 
> -w iw_handler_def drivers), if we can show that rtl8192e, rtl8712 or ks7010 have 
> been broken for a while, removing those would help with removing wext altogether.

I do not know about the the others, but rtl8712 is still in use according to the 
flow of questions I see on a GitHub repo that I maintain.

There has been some recent effort to convert rtl8192e to use cfg/nl/mac80211. 
That one is problematic as it has the same PCI_ID as RTL8192SE, but the drivers 
differ. Note the special code in the probe routine of 
drivers/net/wireless/realtek/rtlwifi/rtl8192se to detect if the wrong one has 
triggered the routine. That code should also be in the probe routine for 
RTL8192E with the test negated. I have both devices, but it has been a long time 
since I actually used either of them. I also have an rtl8712 device, thus I 
should be available for testing.

Larry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ