From: Johannes Berg <johannes@sipsolutions.net>
To: Kalle Valo <kvalo@kernel.org>,
Vinayak Yadawad <vinayak.yadawad@broadcom.com>
Cc: linux-wireless@vger.kernel.org, jithu.jance@broadcom.com,
Arend van Spriel <arend.vanspriel@broadcom.com>,
netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to driver
Date: Mon, 12 Feb 2024 20:58:51 +0100 [thread overview]
Message-ID: <2c38eaed47808a076b6986412f92bb955b0599c3.camel@sipsolutions.net> (raw)
In-Reply-To: <87mss6f8jh.fsf@kernel.org>
On Mon, 2024-02-12 at 09:25 +0200, Kalle Valo wrote:
> What driver is going to use these new crypto settings? Or is this for an
> out-of-tree driver?
>
I'm sure it's for an out-of-tree driver.
This is the _entirety_ of "@broadcom"'s wireless contributions with
"--since=2020" (somewhat arbitrarily chosen, though going a bit further
back has some "real" work in brcmfmac), as far as I can tell:
Arend Van Spriel (1):
cfg80211: adapt to new channelization of the 6GHz band
Arend van Spriel (23):
cfg80211: add VHT rate entries for MCS-10 and MCS-11
brcmfmac: use different error value for invalid ram base address
brcmfmac: increase core revision column aligning core list
brcmfmac: add xtlv support to firmware interface layer
brcmfmac: support chipsets with different core enumeration space
wifi: cfg80211: fix memory leak in query_regdb_file()
wifi: brcmfmac: add function to unbind device to bus layer api
wifi: brcmfmac: add firmware vendor info in driver info
wifi: brcmfmac: add support for vendor-specific firmware api
wifi: brcmfmac: add support for Cypress firmware api
wifi: brcmfmac: add support Broadcom BCA firmware api
wifi: brcmfmac: add vendor name in revinfo debugfs file
wifi: brcmfmac: introduce BRCMFMAC exported symbols namespace
wifi: brcmfmac: avoid handling disabled channels for survey dump
wifi: brcmfmac: avoid NULL-deref in survey dump for 2G only device
wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices
wifi: brcmfmac: change cfg80211_set_channel() name and signature
wifi: brcmfmac: export firmware interface functions
wifi: brcmfmac: add per-vendor feature detection callback
wifi: brcmfmac: move feature overrides before feature_disable
wifi: brcmfmac: avoid invalid list operation when vendor attach fails
wifi: brcmfmac: allow per-vendor event handling
wifi: brcmfmac: add linefeed at end of file
Vinayak Yadawad (4):
wifi: cfg80211: Allow P2P client interface to indicate port authorization
cfg80211: Update Transition Disable policy during port authorization
wifi: cfg80211: Allow AP/P2PGO to indicate port authorization to peer STA/P2PClient
wifi: nl80211: Extend del pmksa support for SAE and OWE security
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.
I guess if Broadcom's plans change they can start by submitting drivers
that actually use the relevant infrastructure.
And note that I've said this to Qualcomm before: I don't really want to
and can't (well) maintain a lot of stuff in the tree that exists there
solely to make out-of-tree drivers happy.
And @Broadcom: we really _want_ you to contribute upstream. But that
shouldn't be dumping APIs over the wall when you need them and letting
us sort out everything else ...
johannes
next parent reply other threads:[~2024-02-12 19:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <309965e8ef4d220053ca7e6bd34393f892ea1bb8.1707486287.git.vinayak.yadawad@broadcom.com>
[not found] ` <87mss6f8jh.fsf@kernel.org>
2024-02-12 19:58 ` Johannes Berg [this message]
2024-02-13 9:42 ` [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups to driver Arend van Spriel
2024-02-13 10:09 ` Johannes Berg
2024-02-13 11:13 ` Arend van Spriel
2024-02-13 11:45 ` Johannes Berg
2024-02-13 12:19 ` Arend van Spriel
2024-02-13 12:30 ` Johannes Berg
2024-02-13 12:50 ` Kalle Valo
2024-02-13 13:43 ` Jithu Jance
2024-02-13 12:46 ` Kalle Valo
2024-02-14 1:43 ` Jakub Kicinski
2024-02-14 10:27 ` Johannes Berg
2024-02-14 16:08 ` Jakub Kicinski
2024-02-14 16:57 ` Jeff Johnson
2024-02-27 19:27 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2c38eaed47808a076b6986412f92bb955b0599c3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend.vanspriel@broadcom.com \
--cc=jithu.jance@broadcom.com \
--cc=kuba@kernel.org \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vinayak.yadawad@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).