Received-SPF: pass (google.com: domain of linux-wireless+bounces-3534-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Kalle Valo <kvalo@kernel.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Vinayak Yadawad <vinayak.yadawad@broadcom.com>,
  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
References: <309965e8ef4d220053ca7e6bd34393f892ea1bb8.1707486287.git.vinayak.yadawad@broadcom.com>
	<87mss6f8jh.fsf@kernel.org>
	<2c38eaed47808a076b6986412f92bb955b0599c3.camel@sipsolutions.net>
Date: Tue, 13 Feb 2024 14:46:59 +0200
In-Reply-To: <2c38eaed47808a076b6986412f92bb955b0599c3.camel@sipsolutions.net>
	(Johannes Berg's message of "Mon, 12 Feb 2024 20:58:51 +0100")
Message-ID: <8734twfs58.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Johannes Berg <johannes@sipsolutions.net> writes:

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

Yeah, we need to make a hard stance here and solve this "throw patches
over the wall and run away as fast as you can" model which corporations
use. If kernel.org wireless is important for you, or your company, then
help us! Don't just expect that we do everything for you, that doesn't
scale.

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

A practical tip I can give to Broadcom is to remind that you have a
great engineer with upstream knowledge: Arend. I recommend utilising him
and asking for guidance anything upstream wireless related. Even better
if all the code coming from Broadcom would go through him.

And thenever you add a new feature to the stack, add support to
brcm80211 driver at the same time. This help Broadcom to get the feature
you need to upstream and the upstream community would have a better
Broadcom driver.

Arend, sorry for dumping more work for you :D

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

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