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

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

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

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches