Neal Gompa <neal@xxxxxxxxx> writes: > On Sat, Oct 7, 2023 at 8:51 AM Hector Martin <marcan@xxxxxxxxx> 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@xxxxxxxxx/ >> > >> >> 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@xxxxxxxxxxxxxxxx/ [2] https://lore.kernel.org/linux-wireless/87fs2k5l1a.fsf@xxxxxxxxxx/ [3] https://docs.kernel.org/ -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
