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