brcmfmac: multi-BSS fails with arbitrary per-BSS MAC addresses

Hi,=0A=
=0A=
I am seeing a reproducible multi-BSS MAC-address handling issue with `brcmf=
mac` when configuring multiple AP interfaces on the same PHY.=0A=
=0A=
## Environment=0A=
=0A=
```=0A=
=0A=
Broadcom chipset:   BCM4366C0=0A=
```=0A=
=0A=
## Summary=0A=
=0A=
A single AP works normally.=0A=
=0A=
Multiple APs also work when either:=0A=
=0A=
1. the default automatically assigned MAC addresses are used, or=0A=
2. explicit `option macaddr` values are configured using the same base addr=
ess, with the first five octets identical and only the last octet different=
.=0A=
=0A=
However, if I configure arbitrary unique MAC addresses for the AP interface=
s, only one AP can be enabled. As soon as a second AP is enabled, multi-BSS=
 operation fails and the AP interfaces disappear / fail to come up.=0A=
=0A=
## Expected behavior=0A=
=0A=
The PHY advertises support for multiple AP interfaces.=0A=
=0A=
Therefore, multiple AP interfaces should be able to operate concurrently as=
 long as each interface is assigned a valid, unique unicast MAC address.=0A=
=0A=
## Actual behavior=0A=
=0A=
### One AP=0A=
=0A=
A single AP works with:=0A=
=0A=
* the default MAC address=0A=
* an explicit same-base MAC address=0A=
* an arbitrary valid MAC address=0A=
=0A=
### Multiple APs using default MAC assignment=0A=
=0A=
Multiple APs work when the default automatically generated addresses are us=
ed.=0A=
=0A=
### Multiple APs using explicit same-base addresses=0A=
=0A=
Multiple APs work when I explicitly configure addresses where the first fiv=
e octets remain identical and only the last octet changes.=0A=
=0A=
Example of a working manually configured pattern:=0A=
=0A=
```=0A=
AP0: AA:BB:CC:DD:EE:01=0A=
AP1: AA:BB:CC:DD:EE:02=0A=
AP2: AA:BB:CC:DD:EE:03=0A=
AP3: AA:BB:CC:DD:EE:04=0A=
```=0A=
=0A=
The final values do not necessarily need to be consecutive, but the first f=
ive octets must remain identical in my tests.=0A=
=0A=
For example, addresses such as these also remain within the working pattern=
:=0A=
=0A=
```=0A=
AP0: AA:BB:CC:DD:EE:11=0A=
AP1: AA:BB:CC:DD:EE:27=0A=
AP2: AA:BB:CC:DD:EE:5A=0A=
AP3: AA:BB:CC:DD:EE:C3=0A=
```=0A=
=0A=
### Multiple APs using arbitrary unique addresses=0A=
=0A=
If the AP interfaces are assigned arbitrary unique MAC addresses, multi-BSS=
 fails.=0A=
=0A=
Keeping only the first three octets=97the vendor/OUI portion=97the same is =
not sufficient.=0A=
=0A=
Example of a failing pattern:=0A=
=0A=
```=0A=
AP0: AA:BB:CC:11:22:33=0A=
AP1: AA:BB:CC:44:55:66=0A=
AP2: AA:BB:CC:77:88:99=0A=
AP3: AA:BB:CC:12:34:56=0A=
```=0A=
=0A=
With one AP enabled, it works.=0A=
=0A=
When a second AP is enabled using this type of address layout, both APs fai=
l / disappear. With three or four configured, all APs fail as well.=0A=
=0A=
## Reproduction=0A=
=0A=
1. Configure one AP with an arbitrary valid MAC address.=0A=
=0A=
   * The AP comes up successfully.=0A=
=0A=
2. Add a second AP on the same PHY with another arbitrary unique MAC addres=
s.=0A=
=0A=
   * Both AP interfaces fail / disappear.=0A=
=0A=
3. Replace the addresses with explicit addresses sharing the same first fiv=
e octets.=0A=
=0A=
   * Both APs come up successfully.=0A=
=0A=
4. Add a third and fourth AP using the same first-five-octet pattern.=0A=
=0A=
   * All configured APs come up successfully.=0A=
=0A=
5. Change the last three octets independently while keeping only the same O=
UI.=0A=
=0A=
   * Multi-BSS fails again.=0A=
=0A=
## Observed address restriction=0A=
=0A=
In my testing, multiple AP interfaces work only when their MAC addresses be=
long to the same narrow address range:=0A=
=0A=
```=0A=
AA:BB:CC:DD:EE:xx=0A=
```=0A=
=0A=
Changing any of the first five octets between AP interfaces causes multi-BS=
S bring-up to fail.=0A=
=0A=
Keeping only the first three octets identical is not enough.=0A=
=0A=
This may indicate that the device or firmware supports only a restricted vi=
rtual-interface address mask or MAC-address pool, but that restriction does=
 not appear to be clearly exposed or enforced before interface creation.=0A=
=0A=
## Related issue=0A=
=0A=
I have also observed a separate AP+STA concurrency issue on the same hardwa=
re where the STA is reassigned to an AP interface=92s MAC address.=0A=
=0A=
I am reporting that separately because its reproduction and failure mode ar=
e different. However, both problems may involve virtual-interface MAC alloc=
ation or firmware interface-address handling.=0A=
=0A=
=0A=
Best regards,=0A=
Stephen=