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

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

Il giorno Thu, 01 Oct 2026 01:31:24 +0000
"andreas.wendleder" <andreas.wendleder@proton.me> ha scritto:

> Hi Alessio,
> 
> Thanks again, and sorry for the delay. I've gone through your repo
> and am working with it. Attached are the SROM dump and the wl traces
> you asked for, then one concrete question.
> 
> Attached (see README.txt inside for formats and conditions):
>  - the raw SROM words of this MacBookAir6,1 (BCM4360, core rev 42,
> radio 2069 rev 4), a rev 11 image, plus the ChipCommon/PMU state with
> our port loaded;
>  - four wl 6.30.223.271 traces, from "unloaded" to BSS up on 2.4 GHz
> and on 5 GHz, plus one with traffic, and an ifdown/ifup;
>  - MAC register snapshots under wl and under our port.
> 
> I have no OTP dump. Our port never reads it and I can't reload wl
> here without a reboot. If you can tell me the ChipCommon OTP read
> sequence for this chip, I'll dump it.

Thank you!

> 
> State. Our port associates and passes traffic on 2.4 GHz (ch11), but
> only about 20-30% of fresh inits come up clean. In the other cases
> the PHY holds carrier sense (phydebug 0x5 = CRS|TXF) with a TX frame
> posted, MAC suspend failed follows, and the ucode sits in NAP (PSM PC
> 0x000f, the end of its scheduler loop). It wakes only about every
> 1-2.5 s. A clean init stays clean for a long time.
> 
> Already tried from your repo, all with no effect on that rate: TX
> FIFO geometry (we already match 0019), object-address read-back
> (0020), MAC setup before PHY plus TSF fraction 0x6614b, the
> PSM_PHY_HDR/FGC pairing, PMU (PLL words already 0x0c31/0x100e,
> max_res_mask forced to 0x7ff), and the CRS threshold forced to 68 and
> 120. A post-init register snapshot of 50 inits shows no static PHY or
> radio difference between good and bad ones, so it looks like a
> runtime wake problem, not an init-state one.
> 
> Question. In your bus captures, what does the stock driver do to keep
> or wake the ucode when it posts TX frames, beyond the single DMA
> pointer write? In our wl trace that write is the only MMIO at a TX
> post, and MACCTL goes 0x44020403 during suspend/enable windows and
> back to 0x40020403 between them. Do you see anything similar, or
> another register (IHR event mask at 0x40, an AWAKE/HWPS rule, a
> periodic wake) that we don't?

WL program the awake bit during every mac suspension to prevent the
ucode from entering sleep. B43 don't do it by default, you have to
patch it.

> 
> Also, if you can share it, the MacBookAir6,1 bus capture of wl 6.30
> from your README would be very useful, since it's our exact hardware.

That is one of your early trace, in fact, i picked up when you wrote to
b43. If you want to see something new, you are better off with T5E
trace, it is the same 6.30 driver on different hardware

> Your PHY code is 5 GHz only so far. Is 2.4 GHz planned?

Yes, since you are giving me a complete 2.4Ghz trace, now i can look on
it. Most logic should be already there, but some fixes maybe be
needed.

> 
> Thanks,
> Andreas