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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
