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

[Alessio Ferri <alessio.ferri@mythread.it>]

On Tue, 29 Sep 2026 08:27:53 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> wrote:

> > Least, but not last, the wl order of macro operation and b43 order
> > are different in multiple places, how did you reconcile the two?  
> 
> Good sign: we're core_rev 42 too, so our disassembly and yours should
> be directly comparable.
> 

I didn't mass disassemble, i just hooked the io accessors, both because
it is faster to learn what the driver is doing and less problematic if
someone ask. Also the trace can be shared, the disassembly does not.

> femctrl/srom: not touched, no handling anywhere in our port. One fixed
> test board, so we've never hit a different value. No data point to
> offer - if you find out what it gates, let me know.

So you harcoded your srom?

> 
> wl order vs b43 order: we captured wl's real register-access sequence
> live (bpftrace kprobes on its own osl_readl/writel/delay, wl left
> loaded and bound throughout - never touch its binding while probes
> attach) and diffed it against our call order, case by case. 
> 
> Sharpest example:
> b43's generic switch_channel calls the per-channel tune, then
> unconditionally re-applies a captured POR snapshot afterward -
> captured during wl's first association, on channel 1. So channel 6
> got tuned correctly, then immediately overwritten back to channel 1's
> values. wl's real order runs the POR replay once at attach, not after
> every switch. Cost us a real mistune bug before the trace diff caught
> it. Smaller example, same category: our TX-cal port was missing one
> PHY register write wl issues between the gain-table override and
> starting the test tone - doesn't crash, just makes the measurement
> never differentiate.
>

But which driver version did you look at? The 6.30 hybrid?