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@xxxxxxxxxxxx> > L: linux-wireless@xxxxxxxxxxxxxxx > L: brcm80211@xxxxxxxxxxxxxxx > L: brcm80211-dev-list.pdl@xxxxxxxxxxxx > 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
