Re: On brcm80211 maintenance and support

Re: On brcm80211 maintenance and support

[Hector Martin]

On 06/10/2023 21.21, Kalle Valo wrote:
> Julian Calaby <julian.calaby@gmail.com> writes:
> 
>> Hi Dmitry,
>>
>> (relevant people and lists CC'd)
>>
>> On Fri, Oct 6, 2023 at 3:16 AM Dmitry Antipov <dmantipov@yandex.ru> 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@gmail.com/
>>
>> 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/4f6223b8083ed69432493a37d4f45b69@mail.gmail.com/
>>
>> 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@marcan.st/
>>
>> 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

Re: On brcm80211 maintenance and support

[Dmitry Antipov]

On 10/6/23 18:34, Hector Martin wrote:

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

Good news. Would you capable to consider some generic (not hooked to any
particular hardware) things like [1] ?

[1] https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/

Dmitry

Re: On brcm80211 maintenance and support

[Hector Martin]

On 07/10/2023 00.48, Dmitry Antipov wrote:
> On 10/6/23 18:34, Hector Martin wrote:
> 
>> 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.
> 
> Good news. Would you capable to consider some generic (not hooked to any
> particular hardware) things like [1] ?
> 
> [1] https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
> 

Sure, I've done cleanup type stuff myself too.

- Hector

Re: On brcm80211 maintenance and support

[Neal Gompa]

On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@marcan.st> wrote:
>
> On 07/10/2023 00.48, Dmitry Antipov wrote:
> > On 10/6/23 18:34, Hector Martin wrote:
> >
> >> 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.
> >
> > Good news. Would you capable to consider some generic (not hooked to any
> > particular hardware) things like [1] ?
> >
> > [1] https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
> >
>
> Sure, I've done cleanup type stuff myself too.
>

Can we please get this done so that the pile of Broadcom patches can
actually start landing again? It's been frustrating watching patch
submissions be ignored for over a year now. At least add Hector as a
co-maintainer and allow him to land stuff people have been using
outside to get Broadcom Wi-Fi to *work*.

Having stuff sit on the pile and be *ignored* is frustrating for
contributors and users, and massively disincentivizes people from
working in upstream Linux.



--
真実はいつも一つ！/ Always, there's only one truth!

Re: On brcm80211 maintenance and support

[Phil Elwell]

Hi everyone,

On Tue, 10 Oct 2023 at 15:53, Neal Gompa <neal@gompa.dev> wrote:
>
> * Spam *
> On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@marcan.st> wrote:
> >
> > On 07/10/2023 00.48, Dmitry Antipov wrote:
> > > On 10/6/23 18:34, Hector Martin wrote:
> > >
> > >> 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.
> > >
> > > Good news. Would you capable to consider some generic (not hooked to any
> > > particular hardware) things like [1] ?
> > >
> > > [1] https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
> > >
> >
> > Sure, I've done cleanup type stuff myself too.
> >
>
> Can we please get this done so that the pile of Broadcom patches can
> actually start landing again? It's been frustrating watching patch
> submissions be ignored for over a year now. At least add Hector as a
> co-maintainer and allow him to land stuff people have been using
> outside to get Broadcom Wi-Fi to *work*.
>
> Having stuff sit on the pile and be *ignored* is frustrating for
> contributors and users, and massively disincentivizes people from
> working in upstream Linux.

This is just a quick note to say that Raspberry Pi obviously has a
vested interest in the future of the brcmfmac driver. In our
downstream tree we use the upstream driver largely unmodified - there
are a handful of patches that tinker around the edges, the largest of
which is in the area of firmware location and being phased out - no
patches from Infineon/Cypress, Synaptics or Broadcom.

We're very much WiFi users as opposed to WiFi developers, but if
there's something useful we can contribute then please speak up and
I'll see what we can do.

Phil

Re: On brcm80211 maintenance and support

[Kalle Valo]

Phil Elwell <phil@raspberrypi.com> writes:

> This is just a quick note to say that Raspberry Pi obviously has a
> vested interest in the future of the brcmfmac driver. In our
> downstream tree we use the upstream driver largely unmodified - there
> are a handful of patches that tinker around the edges, the largest of
> which is in the area of firmware location and being phased out - no
> patches from Infineon/Cypress, Synaptics or Broadcom.
>
> We're very much WiFi users as opposed to WiFi developers, but if
> there's something useful we can contribute then please speak up and
> I'll see what we can do.

Is it possible to run upstream vanilla kernels on a Raspberry Pi? For
example at least once a month take latest wireless-next[1], install it
to a Raspberry Pi and run some simple wireless tests. If any regressions
are found report that to linux-wireless. Preferably with a bisect log to
easily find the offending commit.

Testing patches before they are applied would be even more helpful,
especially for the risky ones. We have a hard "no regressions" rule so
earlier we catch the regressions the better.

I also wonder should there be a dedicated brcm80211 specific mailing
list? That way people who want to help could easily follow and discuss
brcm80211 development, and no need to follow linux-wireless. For example
we do that with ath12k driver.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: On brcm80211 maintenance and support

[Phil Elwell]

Hi Kalle,

On Wed, 11 Oct 2023 at 11:32, Kalle Valo <kvalo@kernel.org> wrote:
>
> Phil Elwell <phil@raspberrypi.com> writes:
>
> > This is just a quick note to say that Raspberry Pi obviously has a
> > vested interest in the future of the brcmfmac driver. In our
> > downstream tree we use the upstream driver largely unmodified - there
> > are a handful of patches that tinker around the edges, the largest of
> > which is in the area of firmware location and being phased out - no
> > patches from Infineon/Cypress, Synaptics or Broadcom.
> >
> > We're very much WiFi users as opposed to WiFi developers, but if
> > there's something useful we can contribute then please speak up and
> > I'll see what we can do.
>
> Is it possible to run upstream vanilla kernels on a Raspberry Pi? For
> example at least once a month take latest wireless-next[1], install it
> to a Raspberry Pi and run some simple wireless tests. If any regressions
> are found report that to linux-wireless. Preferably with a bisect log to
> easily find the offending commit.
>
> Testing patches before they are applied would be even more helpful,
> especially for the risky ones. We have a hard "no regressions" rule so
> earlier we catch the regressions the better.
>
> I also wonder should there be a dedicated brcm80211 specific mailing
> list? That way people who want to help could easily follow and discuss
> brcm80211 development, and no need to follow linux-wireless. For example
> we do that with ath12k driver.

It's a very busy time for us at the moment, but a monthly-ish wireless
smoke test sounds reasonable. Hopefully once we have a process for
that then occasional regression checks on upcoming patches would
become possible.

A dedicated brcm80211 mailing list would be good - I'd definitely sign up.

Phil

Re: On brcm80211 maintenance and support

[Kalle Valo]

Neal Gompa <neal@gompa.dev> writes:

> On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@marcan.st> wrote:
>
>>
>> On 07/10/2023 00.48, Dmitry Antipov wrote:
>> > On 10/6/23 18:34, Hector Martin wrote:
>> >
>> >> 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.
>> >
>> > Good news. Would you capable to consider some generic (not hooked to any
>> > particular hardware) things like [1] ?
>> >
>> > [1]
>> > https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
>> >
>>
>> Sure, I've done cleanup type stuff myself too.
>>
>
> Can we please get this done so that the pile of Broadcom patches can
> actually start landing again? It's been frustrating watching patch
> submissions be ignored for over a year now. At least add Hector as a
> co-maintainer and allow him to land stuff people have been using
> outside to get Broadcom Wi-Fi to *work*.
>
> Having stuff sit on the pile and be *ignored* is frustrating for
> contributors and users, and massively disincentivizes people from
> working in upstream Linux.

Your email reminds me of this comic:

https://xkcd.com/2347/

In the last few years we seem to be getting more of these "Work faster!"
emails and honestly it's getting frustrating for us maintainers. If
Linux wireless is important for you then help us! You can review
patches, run tests on real hardware, write hwsim test cases[1], fix
compiler warnings[2] etc. to help us maintainers and speed up
development. There's so much to do and while you gain experience on the
wireless development you can help even more.

Also take it into account that it's not just simple to "take patches"
and be done with it. There are high quality requirements, the code needs
to have no compiler warnings and must not cause any regressions in
existing setups. That's not easy at all, especially as our hardware
testing is basically limited to few the most active drivers. And let
alone there are very exotic hardware out there and it's impossible to
test all of them.

If you have patches you want to submit to linux-wireless: please read
carefully our documentation (starting from the wiki link below) and then
go to the main Linux documentation[3]. Once you have a good
understanding how we prefer patches to be submitted, submit a patch. But
I always recommend starting from something small, taking baby steps and
learning from the feedback. This gives the best chances of patches being
accepted.

[1] https://lore.kernel.org/linux-wireless/ac1f3d9b81dbca244bdc8262e9d2ee44220f78c1.camel@sipsolutions.net/

[2] https://lore.kernel.org/linux-wireless/87fs2k5l1a.fsf@kernel.org/

[3] https://docs.kernel.org/

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: On brcm80211 maintenance and support

[Hector Martin]

On 2023/10/11 19:23, Kalle Valo wrote:
> Neal Gompa <neal@gompa.dev> writes:
> 
>> On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@marcan.st> wrote:
>>
>>>
>>> On 07/10/2023 00.48, Dmitry Antipov wrote:
>>>> On 10/6/23 18:34, Hector Martin wrote:
>>>>
>>>>> 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.
>>>>
>>>> Good news. Would you capable to consider some generic (not hooked to any
>>>> particular hardware) things like [1] ?
>>>>
>>>> [1]
>>>> https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
>>>>
>>>
>>> Sure, I've done cleanup type stuff myself too.
>>>
>>
>> Can we please get this done so that the pile of Broadcom patches can
>> actually start landing again? It's been frustrating watching patch
>> submissions be ignored for over a year now. At least add Hector as a
>> co-maintainer and allow him to land stuff people have been using
>> outside to get Broadcom Wi-Fi to *work*.
>>
>> Having stuff sit on the pile and be *ignored* is frustrating for
>> contributors and users, and massively disincentivizes people from
>> working in upstream Linux.
> 
> Your email reminds me of this comic:
> 
> https://xkcd.com/2347/
> 
> In the last few years we seem to be getting more of these "Work faster!"
> emails and honestly it's getting frustrating for us maintainers. If
> Linux wireless is important for you then help us! You can review
> patches, run tests on real hardware, write hwsim test cases[1], fix
> compiler warnings[2] etc. to help us maintainers and speed up
> development. There's so much to do and while you gain experience on the
> wireless development you can help even more.
> 
> Also take it into account that it's not just simple to "take patches"
> and be done with it. There are high quality requirements, the code needs
> to have no compiler warnings and must not cause any regressions in
> existing setups. That's not easy at all, especially as our hardware
> testing is basically limited to few the most active drivers. And let
> alone there are very exotic hardware out there and it's impossible to
> test all of them.

I think we need to qualify this "no regressions" "rule". People regress
our machines in mainline all the time. We catch it and get it fixed,
sometimes in RCs, sometimes it goes all the way to stable and needs to
get fixed there. We've had patches break everything from Bluetooth LE
pairing to core memory management to the point we needed earlycon to
diagnose it. That last one was a blatantly wrong patch to core Linux MM,
it wasn't even something specific to our platform, but even that got
past review (it just happened to break us specifically due to a
coincidence).

The review process doesn't magically avoid regressing things. "No
regressions" is impossible without someone actually testing things.
Claiming otherwise is dishonest. So if I end up as maintainer here I
certainly am not going to promise "no regressions" for chips I can't
test, without someone interested in those chips testing them. Of course
I'll take regression fixes when they do happen and someone notices, but
I can't know in advance until someone does.

Consider a patch that changes some codepath in the driver. I can't know
whether the original logic was always broken, or whether it worked on
some chips, and whether the new logic works on those chips or will
regress them, without testing. This is a regular occurrence with
brcmfmac, due to the complexity and variability of the firmware
interface. Often multiple versions of stuff are supported, or some
structures can be extended, but sometimes they can't. It's a mess, and
without firmware source code nor any official specs, there is no way to
know exactly what is intended and what the backwards compatibility
requirements are.

The only way to avoid that is to gratuitously introduce version/chip
gates for *every single change affecting behavior from the firmware
POV*, which is a complete non-starter and would quickly yield a giant
mess of spaghetti code. It's bad enough having to support explicit
ABI-breaking changes in firmware, and having to deal with multiple
versions of huge structures and convert between them. Trying to outright
keep existing logic identical for "other chips" is just not going to
happen, not without first having confirmation of what the requirements
are from someone who has the required docs/source.

I have a patch to enable WPA3 in Broadcom chipsets (yes, the driver is
in such a sorry state it doesn't even support that yet). The current
support attempt was added by a Cypress engineer and uses a completely
different firmware mechanism. Is that supposed to actually work? Does it
work currently? Is that the case for all Cypress firmwares? Or only
some? Does the alternate mechanism we have for Broadcom chips work too?
Only Cypress can answer those questions ahead of time, and they aren't
(they ignored me last time I brought this up). So my current patch just
replaces the mechanism with the known-working one for Broadcom chips.

Next time I send a bunch of our downstream patches, I'm going to resend
that WPA3 patch. And if it regresses Cypress WPA3 support, tough luck.
If someone catches it (Phil?) and it turns out the existing support is
the only way to do things on Cypress, I'll rework the patch to
conditionally support both styles. But if nobody does, and nobody cares,
then I'm sorry if I regress things, but there is no way to avoid it. We
can't be gratuitously gating every single change just to hope to avoid
regressions, without any confirmation of what is required. That just
doesn't scale.

Phil: Given Cypress' complete apathy towards this driver, if you want
the Cypress chips in Raspberry Pi systems to continue working and catch
potential problems ahead of time, it would be helpful if you can test
the patches in this branch. This is our downstream brcmfmac patchset.
Regardless of what ends up happening with the maintainer situation,
giving this a whirl will be very helpful in catching problems with
systems people actually use. It should be easy to bisect regressions too
(we keep this rebased directly on recent kernels so you can apply it on
top of your tree or whatever).

https://github.com/asahilinux/linux/tree/bits/080-wifi

- Hector

Re: On brcm80211 maintenance and support

[Phil Elwell]

On Wed, 11 Oct 2023 at 12:28, Hector Martin <marcan@marcan.st> wrote:
> I think we need to qualify this "no regressions" "rule". People regress
> our machines in mainline all the time. We catch it and get it fixed,
> sometimes in RCs, sometimes it goes all the way to stable and needs to
> get fixed there. We've had patches break everything from Bluetooth LE
> pairing to core memory management to the point we needed earlycon to
> diagnose it. That last one was a blatantly wrong patch to core Linux MM,
> it wasn't even something specific to our platform, but even that got
> past review (it just happened to break us specifically due to a
> coincidence).
>
> The review process doesn't magically avoid regressing things. "No
> regressions" is impossible without someone actually testing things.
> Claiming otherwise is dishonest. So if I end up as maintainer here I
> certainly am not going to promise "no regressions" for chips I can't
> test, without someone interested in those chips testing them. Of course
> I'll take regression fixes when they do happen and someone notices, but
> I can't know in advance until someone does.
>
> Consider a patch that changes some codepath in the driver. I can't know
> whether the original logic was always broken, or whether it worked on
> some chips, and whether the new logic works on those chips or will
> regress them, without testing. This is a regular occurrence with
> brcmfmac, due to the complexity and variability of the firmware
> interface. Often multiple versions of stuff are supported, or some
> structures can be extended, but sometimes they can't. It's a mess, and
> without firmware source code nor any official specs, there is no way to
> know exactly what is intended and what the backwards compatibility
> requirements are.
>
> The only way to avoid that is to gratuitously introduce version/chip
> gates for *every single change affecting behavior from the firmware
> POV*, which is a complete non-starter and would quickly yield a giant
> mess of spaghetti code. It's bad enough having to support explicit
> ABI-breaking changes in firmware, and having to deal with multiple
> versions of huge structures and convert between them. Trying to outright
> keep existing logic identical for "other chips" is just not going to
> happen, not without first having confirmation of what the requirements
> are from someone who has the required docs/source.
>
> I have a patch to enable WPA3 in Broadcom chipsets (yes, the driver is
> in such a sorry state it doesn't even support that yet). The current
> support attempt was added by a Cypress engineer and uses a completely
> different firmware mechanism. Is that supposed to actually work? Does it
> work currently? Is that the case for all Cypress firmwares? Or only
> some? Does the alternate mechanism we have for Broadcom chips work too?
> Only Cypress can answer those questions ahead of time, and they aren't
> (they ignored me last time I brought this up). So my current patch just
> replaces the mechanism with the known-working one for Broadcom chips.
>
> Next time I send a bunch of our downstream patches, I'm going to resend
> that WPA3 patch. And if it regresses Cypress WPA3 support, tough luck.
> If someone catches it (Phil?) and it turns out the existing support is
> the only way to do things on Cypress, I'll rework the patch to
> conditionally support both styles. But if nobody does, and nobody cares,
> then I'm sorry if I regress things, but there is no way to avoid it. We
> can't be gratuitously gating every single change just to hope to avoid
> regressions, without any confirmation of what is required. That just
> doesn't scale.
>
> Phil: Given Cypress' complete apathy towards this driver, if you want
> the Cypress chips in Raspberry Pi systems to continue working and catch
> potential problems ahead of time, it would be helpful if you can test
> the patches in this branch. This is our downstream brcmfmac patchset.
> Regardless of what ends up happening with the maintainer situation,
> giving this a whirl will be very helpful in catching problems with
> systems people actually use. It should be easy to bisect regressions too
> (we keep this rebased directly on recent kernels so you can apply it on
> top of your tree or whatever).
>
> https://github.com/asahilinux/linux/tree/bits/080-wifi

That sounds like a reasonable starting point - I'll take a look.

Phil

Re: On brcm80211 maintenance and support

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 7374 bytes --]

On 10/11/2023 1:28 PM, 'Hector Martin' via BRCM80211-DEV-LIST,PDL wrote:
> 
> 
> On 2023/10/11 19:23, Kalle Valo wrote:
>> Neal Gompa <neal@gompa.dev> writes:
>>
>>> On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@marcan.st> wrote:
>>>
>>>>
>>>> On 07/10/2023 00.48, Dmitry Antipov wrote:
>>>>> On 10/6/23 18:34, Hector Martin wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Good news. Would you capable to consider some generic (not hooked to any
>>>>> particular hardware) things like [1] ?
>>>>>
>>>>> [1]
>>>>> https://lore.kernel.org/linux-wireless/20230703162458.155942-1-dmantipov@yandex.ru/
>>>>>
>>>>
>>>> Sure, I've done cleanup type stuff myself too.
>>>>
>>>
>>> Can we please get this done so that the pile of Broadcom patches can
>>> actually start landing again? It's been frustrating watching patch
>>> submissions be ignored for over a year now. At least add Hector as a
>>> co-maintainer and allow him to land stuff people have been using
>>> outside to get Broadcom Wi-Fi to *work*.
>>>
>>> Having stuff sit on the pile and be *ignored* is frustrating for
>>> contributors and users, and massively disincentivizes people from
>>> working in upstream Linux.
>>
>> Your email reminds me of this comic:
>>
>> https://xkcd.com/2347/
>>
>> In the last few years we seem to be getting more of these "Work faster!"
>> emails and honestly it's getting frustrating for us maintainers. If
>> Linux wireless is important for you then help us! You can review
>> patches, run tests on real hardware, write hwsim test cases[1], fix
>> compiler warnings[2] etc. to help us maintainers and speed up
>> development. There's so much to do and while you gain experience on the
>> wireless development you can help even more.
>>
>> Also take it into account that it's not just simple to "take patches"
>> and be done with it. There are high quality requirements, the code needs
>> to have no compiler warnings and must not cause any regressions in
>> existing setups. That's not easy at all, especially as our hardware
>> testing is basically limited to few the most active drivers. And let
>> alone there are very exotic hardware out there and it's impossible to
>> test all of them.
> 
> I think we need to qualify this "no regressions" "rule". People regress
> our machines in mainline all the time. We catch it and get it fixed,
> sometimes in RCs, sometimes it goes all the way to stable and needs to
> get fixed there. We've had patches break everything from Bluetooth LE
> pairing to core memory management to the point we needed earlycon to
> diagnose it. That last one was a blatantly wrong patch to core Linux MM,
> it wasn't even something specific to our platform, but even that got
> past review (it just happened to break us specifically due to a
> coincidence).
> 
> The review process doesn't magically avoid regressing things. "No
> regressions" is impossible without someone actually testing things.
> Claiming otherwise is dishonest. So if I end up as maintainer here I
> certainly am not going to promise "no regressions" for chips I can't
> test, without someone interested in those chips testing them. Of course
> I'll take regression fixes when they do happen and someone notices, but
> I can't know in advance until someone does.

I do not think Kalle was claiming that. Regression will happen as it is 
simply not possible to verify each patch on all devices supported by the 
driver.

> Consider a patch that changes some codepath in the driver. I can't know
> whether the original logic was always broken, or whether it worked on
> some chips, and whether the new logic works on those chips or will
> regress them, without testing. This is a regular occurrence with
> brcmfmac, due to the complexity and variability of the firmware
> interface. Often multiple versions of stuff are supported, or some
> structures can be extended, but sometimes they can't. It's a mess, and
> without firmware source code nor any official specs, there is no way to
> know exactly what is intended and what the backwards compatibility
> requirements are.
> 
> The only way to avoid that is to gratuitously introduce version/chip
> gates for *every single change affecting behavior from the firmware
> POV*, which is a complete non-starter and would quickly yield a giant
> mess of spaghetti code. It's bad enough having to support explicit
> ABI-breaking changes in firmware, and having to deal with multiple
> versions of huge structures and convert between them. Trying to outright
> keep existing logic identical for "other chips" is just not going to
> happen, not without first having confirmation of what the requirements
> are from someone who has the required docs/source.

> I have a patch to enable WPA3 in Broadcom chipsets (yes, the driver is
> in such a sorry state it doesn't even support that yet). The current
> support attempt was added by a Cypress engineer and uses a completely
> different firmware mechanism. Is that supposed to actually work? Does it
> work currently? Is that the case for all Cypress firmwares? Or only
> some? Does the alternate mechanism we have for Broadcom chips work too?
> Only Cypress can answer those questions ahead of time, and they aren't
> (they ignored me last time I brought this up). So my current patch just
> replaces the mechanism with the known-working one for Broadcom chips.

This is mainly why I introduced the vendor-split concept so we can keep 
the Cypress mechanism and allow a different mechanism for Broadcom 
chips. The Cypress mechanism did not work for the Broadcom chips I have 
so I wanted to test it on the Cypress chips I got shipped long ago and 
they simply do not come up. Have not tried with RPi as it is not running 
vanilla kernel. Could try with a backports driver.

> Next time I send a bunch of our downstream patches, I'm going to resend
> that WPA3 patch. And if it regresses Cypress WPA3 support, tough luck.
> If someone catches it (Phil?) and it turns out the existing support is
> the only way to do things on Cypress, I'll rework the patch to
> conditionally support both styles. But if nobody does, and nobody cares,
> then I'm sorry if I regress things, but there is no way to avoid it. We
> can't be gratuitously gating every single change just to hope to avoid
> regressions, without any confirmation of what is required. That just
> doesn't scale.

The "no regressions" rule is an important one throughout the kernel. 
Trying to avoid it makes sense, but I have to agree that for brcmfmac 
there is not enough coverage to give any guarantee. As long you are 
prepared to fix things when a regression report comes in that should be 
fine depending on how often there is a need to revert/fix things as it 
can disrupt the normal flow of patches.

Regards,
Arend

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: On brcm80211 maintenance and support

[Florian Fainelli]

On 10/12/23 01:41, Arend van Spriel wrote:
[snip]
>> I have a patch to enable WPA3 in Broadcom chipsets (yes, the driver is
>> in such a sorry state it doesn't even support that yet). The current
>> support attempt was added by a Cypress engineer and uses a completely
>> different firmware mechanism. Is that supposed to actually work? Does it
>> work currently? Is that the case for all Cypress firmwares? Or only
>> some? Does the alternate mechanism we have for Broadcom chips work too?
>> Only Cypress can answer those questions ahead of time, and they aren't
>> (they ignored me last time I brought this up). So my current patch just
>> replaces the mechanism with the known-working one for Broadcom chips.
> 
> This is mainly why I introduced the vendor-split concept so we can keep 
> the Cypress mechanism and allow a different mechanism for Broadcom 
> chips. The Cypress mechanism did not work for the Broadcom chips I have 
> so I wanted to test it on the Cypress chips I got shipped long ago and 
> they simply do not come up. Have not tried with RPi as it is not running 
> vanilla kernel. Could try with a backports driver.

You can run mainline on all of the Raspberry Pi devices, as far as Wi-Fi 
is concerned I cannot think of any major roadblocks, if not, email me 
privately and we can figure this one out.
-- 
Florian