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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 14 Feb 2024 11:27:42 +0100 Johannes Berg wrote:
> > 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.

Right, right, I know that's not the core of your complaint. More of an
adjacent question about somehow reflecting the "vendor engagement level"

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

To a large extent I think it's on us to define what "paid to look after
a driver" means. Any line we draw, no matter how arbitrary, can be used
by the developers to justify the time spent working upstream to their
management. Or so I hope.

Since Broadcom didn't abandon client WiFi chipsets, wouldn't it be
reasonable to expect someone to work on the upstream driver at least
half time?

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

Ack, I'm curious what would end up happening. It's not the primary
reason for working on a shared test pool just a potential side benefit.

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