linux-kernel - Re: On brcm80211 maintenance and support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Oct 2023 13:23:22 +0300
From:   Kalle Valo <kvalo@...nel.org>
To:     Neal Gompa <neal@...pa.dev>
Cc:     Hector Martin <marcan@...can.st>,
        Dmitry Antipov <dmantipov@...dex.ru>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>,
        Arend van Spriel <aspriel@...il.com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        SHA-cyfmac-dev-list@...ineon.com,
        brcm80211-dev-list.pdl@...adcom.com,
        Asahi Linux <asahi@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>,
        Julian Calaby <julian.calaby@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Phil Elwell <phil@...pberrypi.org>
Subject: Re: On brcm80211 maintenance and support

Neal Gompa <neal@...pa.dev> writes:

> On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@...can.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