On 06/10/2023 21.21, Kalle Valo wrote: > Julian Calaby <julian.calaby@xxxxxxxxx> writes: > >> Hi Dmitry, >> >> (relevant people and lists CC'd) >> >> On Fri, Oct 6, 2023 at 3:16 AM Dmitry Antipov <dmantipov@xxxxxxxxx> wrote: >>> >>> Kalle, >>> >>> what's an actual status of brcm80211 driver? It seems >>> that the relevant MAINTAINERS entries are no longer >>> useful, and [1] states that Broadcom is just "disappeared". >> >> Arend hasn't posted since February: >> https://lore.kernel.org/linux-wireless/63f72045-e51d-d9a4-a0ed-c221bcdcee03@xxxxxxxxx/ >> >> Franky is still reviewing things as of early August: >> https://lore.kernel.org/linux-wireless/CA+8PC_evb-6Y3dKnAN4BN=ODEVxY5-cDb6Lc72u0j1WBtx7p1A@xxxxxxxxxxxxxx/ >> >> Hante hasn't posted since 2018: >> https://lore.kernel.org/linux-wireless/4f6223b8083ed69432493a37d4f45b69@xxxxxxxxxxxxxx/ >> >> Hector Martin has a bunch of Apple-specific patches downstream in the >> Asahi Linux kernel and has been looking for guidance on how to >> upstream it without any real answers: >> https://lore.kernel.org/linux-wireless/181af6e9-799d-b730-dc14-ee2de2541f35@xxxxxxxxx/ >> >> There's also speculation that the Raspberry Pi people have downstream >> patches too, but I haven't been able to find anything concrete in a >> very brief search. > > Thanks for the research, that is helpful. > >> Finally, the Cypress / Infineon people appear to be uninterested in >> discussing the driver. >> >> I think it's pretty safe to say that this driver is nearly >> unmaintained by Broadcom, definitely unmaintained by Cypress / >> Infineon and Arend is unable to answer questions relating to anything >> beyond the code as-written. >> >> Kalle, should this driver get orphaned? > > We definitely need to consider that but let's first wait for Arend to > comment. > For better or worse, if nobody else does, I'm willing to sign up to maintain the chips shipping on Apple ARM64 machines (i.e. BCM4378, BCM4387, BCM4388 - that last one I have bringup for downstream, just got it done this week) and partially BCM4377 as a bonus (since I have access to an older Intel Mac with that one, and already did bringup for it, though my access is sporadic). I'm already playing part time maintainer anyway (other folks have already sent us patches I'll have to upstream), and we need this driver to keep working and continue to support new chips. I don't have much time to work on new feature development beyond the basics (STA mode) but I will gladly take patches to add/fix new stuff from others and test them. I'm in a decently good position to test across all the aforementioned chips, and even ship that stuff ahead of time in our downstream tree and get tons of user testing before it goes upstream. Someone already volunteered a patch to fix AP mode that is going into our next downstream kernel builds as well as 6GHz support from someone else. I also have a decently modern home WiFi network (UniFi) so I can set up test SSIDs with specific characteristics and whatnot. However, I make no promises about any other chips. I *especially* make no promises about Cypress / Infineon variants, since as far as I can tell they seem completely uninterested in working with anyone. If they were consistent it wouldn't be a big deal, but it seems they are increasingly forking the firmware ABI, and without cooperation from them there is just no chance whatsoever to support their stuff, and I'm not going to sign up to do their job. I have more than enough work figuring out Broadcom's chips without their help. As for Broadcom, the right logic to gate firmware API structure changes is often anyone's guess. Sometimes they have actual feature flags we can use, sometimes they don't, and when it's based on WL version there's no chance anyone outside of Broadcom knows what the specific supported branches are with accuracy. So basically, any time we get this wrong we might break some chips/firmwares, and there is no way to know. All I can do is make sure the chips Apple ships work with the firmwares Apple ships. No more, no less. For reference on just how painful this is without Broadcom's help, this week I spent an entire day figuring out a single line of code that I had to remove (gate) to stop BCM4388 firmware from crashing and asserting on startup. And that is having access to (some random fork I found on GitHub of) the "open source" bcmdhd driver with support for that chip - even with that, it's picking out a needle in a haystack, and I often end up porting/reimplementing random features from it we don't actually need just hoping I can eventually find the "magic" thing that makes it work. This time around, lovely Broadcom even decided to censor out some headers so I had to reverse engineer some stuff by tracing what Apple's driver does. It can be done, and I will get it done, but only for our chips, there is no chance in hell I can afford to spend time on anything else. - Hector
