Hi Andreas, I'm the former maintainer of b43, so I think I can give at least a few hints. The driver has largely been developed with a clean-room approach and with a register-dump-then-implement approach. There were no lawyers involved. Only common sense. So I think if you use one of these approaches, you are fine. It's also fine in my opinion to use AI assistance up to a point. What I think is very risky is to use AI for the whole process. I think there must be a human involved to review the specification for copyrighted material. But also for quality control. If the whole thing is based solely on register dumping, my personal lay opinion is that there cannot be much copyrighted material in there. So, yeah. Feel free to post both your specification and your implementation if you like. Please also fully disclose how the intermediate steps were developed and what role AI assistance played. Then we can decide how to continue. I hope that not too many changes to the existing common parts and other PHYs are needed, to keep the regression risk low. -- Michael Büsch https://bues.ch/ On Mon, 28 Sep 2026 13:42:42 +0000 "andreas.wendleder" wrote: > 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?