AW: BCM4360 AC-PHY support for b43 — reverse-engineered, seeking guidance on a clean path upstream

[andreas.wendleder]

Hi,
I've been working on adding 802.11ac AC-PHY support to b43 for the BCM4360 (MacBookAir6,1), since b43's existing phy_ac.c has only ever been a skeleton (allocate/free plumbing, no real init or tuning) and Broadcom's own wl driver is the only thing that's ever actually worked on this chip.

I want to be upfront about how I got there, since it directly affects what (if anything) is submittable: I reverse-engineered wl.ko — decompiling it and capturing its live register/SHM writes on real hardware — and used that to write a working driver. That driver is not clean-room and I'm not proposing to submit it as-is; having the proprietary driver's decompiled logic in view while writing it is a real provenance problem, not just a style one.

What I am hoping is more useful: I've since written up a functional specification — chip bring-up, channel tuning, TX/RX header formats, and the specific pitfalls that cost real debugging time (a frame-lifetime register that silently stalls connections if left unset, an RX status bit that looks like "decrypt error" but fires on unencrypted frames too) — describing the hardware's required behavior in my own words, with the intent that someone who's never seen wl.ko or my driver could implement a working driver from just that document and the 802.11 spec. It's honest about what it doesn't include (the actual calibration/tuning table numbers, firmware, b43's existing generic infrastructure) and upfront that I'm not qualified to judge its legal soundness alone.

The driver itself works: verified WPA2 association, DHCP, and sustained stable traffic on 2.4 GHz, on both the kernel this project started on and, as of today, kernel 7.2.7 with no code changes needed. 5 GHz, hardware crypto, and full RF calibration are out of scope so far.
Given b43 is listed Orphan, I don't have a specific person to ask, so: has this kind of provenance situation — a reverse-engineered spec intended to enable an independent clean-room implementation — come up before for a wireless driver here? Is that a viable path at all, and if so, what would you want to see before it's worth anyone's time to attempt the clean-room side?

Thanks for reading this far.

Andreas