On 06/10/2023 21.21, Kalle Valo wrote:
> Julian Calaby <[email protected]> writes:
>
>> Hi Dmitry,
>>
>> (relevant people and lists CC'd)
>>
>> On Fri, Oct 6, 2023 at 3:16 AM Dmitry Antipov <[email protected]> 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/[email protected]/
>>
>> Franky is still reviewing things as of early August:
>> https://lore.kernel.org/linux-wireless/CA+8PC_evb-6Y3dKnAN4BN=ODEVxY5-cDb6Lc72u0j1WBtx7p1A@mail.gmail.com/
>>
>> Hante hasn't posted since 2018:
>> https://lore.kernel.org/linux-wireless/[email protected]/
>>
>> 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/[email protected]/
>>
>> 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