netdev - Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to driver

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: <df8f02b1-25b0-4dae-a935-cee9ba7f3dc4@broadcom.com>
Date: Tue, 13 Feb 2024 12:13:57 +0100
From: Arend van Spriel <arend.vanspriel@...adcom.com>
To: Johannes Berg <johannes@...solutions.net>, Kalle Valo <kvalo@...nel.org>,
 Vinayak Yadawad <vinayak.yadawad@...adcom.com>
Cc: linux-wireless@...r.kernel.org, jithu.jance@...adcom.com,
 netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to
 driver

On 2/13/2024 11:09 AM, Johannes Berg wrote:
> On Tue, 2024-02-13 at 10:42 +0100, Arend van Spriel wrote:
>>> So looks to me like Broadcom doesn't want its (real) drivers to work in
>>> upstream, so I guess we really ought to just stop accommodating for them
>>> in the wireless stack... This only works if we collaborate, and I've
>>> said this before: I can't maintain something well that I cannot see (and
>>> possibly change) the user(s) of.
>>
>> Understood and you are right. The brcm80211 drivers, which are not less
>> real ;-) , were a side-project to serve a certain group of customers.
> 
> It's a real driver, fair enough. But yeah, you do get the sense that
> whatever it is, it really "was" and "isn't" any more.
> 
>> Unfortunately it never became the main driver for Broadcom. Cypress did
>> invest in brcmfmac, but we know how that went since Infineon took over.
>> Maybe they will upstream the ifxfmac driver [1] some day but I have no
>> high hopes on that.
> 
> That doesn't even look super awful, they could probably drop it into
> staging as is ...
> 
> But that'd mean somebody actually cares, which really seems to be the
> problem.
> 
> But since clearly there's no incentive for anyone here in this game to
> upstream anything to start with, I also don't see why I should give more
> incentive to _not_ upstream things by accommodating non-upstream drivers
> in the upstream wifi stack...
> 
> So I'm dropping this patch, Broadcom can decide what they want first,
> but you can't have both upstream and non-upstream together.
> 
> And for the record, I'm very happy that you have and still are
> maintaining this driver as far as it's come.

Thanks for the record ;-) I recall the rule was that nl80211 API changes 
should also have at least one driver implementing it. Guess we let that 
slip a couple of times. I fully agree enforcing this. FWIW I am actually 
planning on submitting brcmfmac patches to support 
NL80211_CMD_EXTERNAL_AUTH.

Gr. AvS

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4219 bytes)