linux-kernel - Re: [PATCH wireless v2] wifi: wlcore: fix wlcore AP mode

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] [day] [month] [year] [list]

Date: Tue, 18 Jun 2024 19:50:25 +0300
From: "Nemanov, Michael" <michael.nemanov@...com>
To: Kalle Valo <kvalo@...nel.org>,
        "Russell King (Oracle)"
	<linux@...linux.org.uk>
CC: Johannes Berg <johannes.berg@...el.com>, <linux-kernel@...r.kernel.org>,
        <linux-wireless@...r.kernel.org>
Subject: Re: [PATCH wireless v2] wifi: wlcore: fix wlcore AP mode

On 6/18/2024 12:16 PM, Kalle Valo wrote:
> 
> "Russell King (Oracle)" <linux@...linux.org.uk> writes:
> 
>> On Mon, Jun 17, 2024 at 01:56:48PM +0300, Kalle Valo wrote:
>>> "Russell King (Oracle)" <linux@...linux.org.uk> writes:
>>> 
>>> > I see all my TI Wilink patches have been marked as "deferred" in the
>>> > wireless patchwork. Please could you explain what the plan is with
>>> > these patches, especially this one which fixes a serious frustrating
>>> > failing that makes AP mode on this hardware very unreliable and thus
>>> > useless.
>>> 
>>> I'm just swamped with patches, I'll try to look at these soon.
>>> 
>>> I wish that TI would take a more active role in upstream, for example
>>> reviewing and testing patches would help a lot.
>>
>> I believe the problem has been that TI have had an attitude of "we
>> only support people using 4.19.38, if you can't reproduce the problem
>> there we aren't interested". To see the versions they support:
>>
>> https://git.ti.com/cgit/wilink8-wlan/build-utilites/tree/patches/kernel_patches?h=r8.9&id=a2ee50aa5190ed3b334373d6cd09b1bff56ffcf7
>>
>> basically, all are ancient.
>>
>> They also appear take the attitude that all the kernel code is ripe
>> for them to hack about with - whcih is why this fix has had to be
>> reworked so it isn't removing NL80211_FEATURE_FULL_AP_CLIENT_STATE
>> for _all_ kernel wireless drivers!
>>
>> Also, I think they also require one to use their hostapd and
>> wpa_supplicant, probably for a similar reason. I know that in some
>> of the patches they've hacked in API changes...
>>
>> Then one can see the attitude of lock-step firmware and driver
>> upgrade - you can't use 8.9.1.x.x firmware with their older driver,
>> and you can't use 8.9.0.x.x with their newer driver. That, of course,
>> is not acceptable to mainline.
>>
>> So, given all this, IMHO it's probably a good thing TI aren't trying
>> to submit their stuff upstream... that is, unless they are willing
>> to learn how to "do things correctly".
>>
>> Maybe I'm being too hard on TI's wireless division, but that seems to
>> be what has been going on.
> 
> Yeah, the all you describe above is very common in wireless vendors :/
> But vendors do learn, Realtek is a great example of that. Let's hope
> that TI does too.

I can say that the driver for the next generation of chips (CC33xx) does 
not and will not require any modifications to mac80211, cfg80211 and 
supplicant.

I will also try to aid and review patches for wl18xx.

Michael.