Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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
