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: <6641f3f90bdc1d24f3a7fd795be672ce02685630.camel@sipsolutions.net>
Date: Wed, 14 Feb 2024 11:27:42 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Kalle Valo <kvalo@...nel.org>, Vinayak Yadawad
	 <vinayak.yadawad@...adcom.com>, linux-wireless@...r.kernel.org, 
	jithu.jance@...adcom.com, Arend van Spriel <arend.vanspriel@...adcom.com>, 
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] wifi: nl80211: Add support for plumbing SAE groups
 to driver

On Tue, 2024-02-13 at 17:43 -0800, Jakub Kicinski wrote:
> I may be missing the point but is there any official way we can
> designate level of vendor involvement? MAINTAINERS seems like 
> the most basic, and we have
> 
> BROADCOM BRCM80211 IEEE802.11 WIRELESS DRIVERS
> M:	Arend van Spriel <arend.vanspriel@...adcom.com>
> L:	linux-wireless@...r.kernel.org
> L:	brcm80211@...ts.linux.dev
> L:	brcm80211-dev-list.pdl@...adcom.com
> S:	Supported
> F:	drivers/net/wireless/broadcom/brcm80211/
> F:	include/linux/platform_data/brcmfmac.h
> 
> where (for the uninitiated):
> 
>    Supported:	Someone is actually paid to look after this.
> 
> It doesn't seem like Arend is afforded much paid time "to look after
> this".

I don't know if that's even the core of my complaint. I don't know if
it's true, but let's assume Arend _does_ get sufficient time to take
care of the driver.

The core of the complaint here is that regardless of that, Broadcom is
treating the driver as a dead end, a fork in the road they're no longer
travelling. So "supporting" that driver may all be well, in the sense
that it's there for the existing hardware/firmware that it supports.

But! It's not getting new features nor support for new devices, I don't
even know if it still supports newer firmware images for the devices it
already supports. Some new driver support is coming in by way of the
Apple-support folks, but you saw how that's going ...

Yet at the same time Broadcom _are_ sending patches to the core wifi
stack, in order to support new features/offloads for their new firmware
builds etc. on some/other/new devices. New features for the stack where
we cannot actually see the driver implementation, maintain it, etc. Not
that in many cases the driver implementation would be all that
interesting, but it's still pushing code and work into upstream that it
will never benefit from.

So this disconnect really is the complaint: Broadcom want us to maintain
the stack for them, do things for them like in this patch in support of
their latest firmware builds, but they definitely do _not_ want to do
anything upstream that would actually support these new things they
have.

At which point, yeah, I'm putting my foot down and saying this has to
stop. I really don't (**) care about Broadcom doing their own vendor-
specific APIs if there's zero chance the things they're needed for will
ever land upstream anyway.

(**) No longer. I used to think that being more open about this would
encourage folks to start a journey of contributing more upstream, but
clearly that hasn't worked out.

Now this is why I used to be more open: I will also most definitely not
accept all the vendor APIs upstream if someone later decides they do
want an upstream driver, and then push all the vendor stuff on grounds
that "it's used now and we have to support it" ... We don't, at least
not upstream, what you sell to your customers really isn't our problem.

(And to be honest, if customers cared, we'd not be in this position)

> On the Ethernet side I have a nebulous hope to require vendors who want
> the "Supported" status to run our in-tree tests against their HW daily.
> As a way to trigger the loss of status. Otherwise it's hard to catch
> people drifting away.

Every day seems a bit excessive? OTOH, every day is a good way of saying
"you really have to automate this", but then once you do that, maybe you
don't need to pay anyone to really maintain it, beyond trying to keep
the tests running?

Also not sure what that status really implies, I think Broadcom would be
quite happy to just mark the driver as orphaned...

johannes