[PATCH wireless-next 0/3] wifi: Preamble puncturing support for mesh

[Ramasamy Kaliappan]

On 6/30/2025 6:51 PM, Johannes Berg wrote:
> On Fri, 2025-06-27 at 19:49 +0530, Ramasamy Kaliappan wrote:
>>> I ... don't really understand how this is supposed to work.
>>>
>>> Say, for the sake of simplicity, we have an 80 MHz channel, the lowest
>>> channel is the control channel (so puncturing 0x1 is invalid). Possible
>>> puncturing values are 0x2, 0x4 and 0x8.
>>>
>>> If locally we have 0x2, that means (I assume, since that's how chandef
>>> is meant to work) CCA and RX is always on the control channel and upper
>>> 40 MHz parts. If you're now going to transmit to a station that has
>>> puncturing 0x8, you didn't do CCA on the 0x2 subchannel, but ...
>>> transmit anyway?
>>>
>> Yes,we do not transmit blindly to mesh peers with different puncturing.
>> Before initiating transmission, the driver computes the intersection of
>> the local and peer puncturing bitmaps to determine the set of valid sub
>> channels.
> 
> Hm, I guess that's fair, but why not do that in mac80211 instead, that'd
> be simpler and far more obvious/safe?
> 

Hmm, I originally thought the bandwidth determination would need to 
happen within the driver,  since it’s required at the time of packet 
transmission for each mesh STA. The assumption was partly influenced by 
our existing firmware design.

But yeah, since the bandwidth doesn’t really change much across PPDUs 
for the same STA, it actually makes more sense to handle it in mac80211 
and drivers can use it.

> Also, clearly your driver _doesn't_ do what you say "the driver" does,
> if anything it magically and "undocumentedly" happens in firmware.
> 

Yes that's right, the intersection and BW selection is done for every 
PPDU at Firmware.

>>> I mean, maybe this could work if the remote puncturing is a superset of
>>> the local puncturing? But just blindly doing it the way it appears to be
>>> done in this patchset seems ... questionable at best?
>>>
>>> Can you explain more how this is even supposed to work?
>>>
>> When associating with a mesh peer, the mesh peer's puncture pattern is
>> shared with the driver. The driver evaluates the intersection of this
>> bitmap with local pattern.
> 
> Could also be done in mac80211, I guess.
> 

Thats right

>> if the resulting pattern corresponds to valid transmission bandwidth,
>> the valid subchannels used for transmission.
>>
>> If the resulting pattern does not support a valid bandwidth, the driver
>> falls back to using only the primary 20 MHz control channel for
>> transmission.
> 
> Right.
> 
> I also note that there's not even any definition where the puncturing
> pattern is rooted ... is it relative to the local chandef? Relative to
> the peer's chandef? Clearly not even that is documented.


When not considering CSA scenario then the puncturing pattern is an 
intersection of the local channel def and puncturing pattern advertised 
by peer.

If the local and peer mesh are capable of EHT, the negotiated EHT 
bandwidth of the peer mesh is considered first. The intersection of 
puncturing patterns is then applied on top of this to derive 
bandwidth—potentially reduced and with or without additional puncturing.

> What happens if
> the bitmap changes? Why does userspace track it rather than mac80211,

When a channel switch is triggered by a userspace application,
the user space is fully aware of the bitmap changes and pass them to the 
mac80211 driver.
But when a peer mesh initiates a channel switch via CSA, the mac80211 
driver on the local mesh receives bitmap changes through CSA 
beacon/action frames and processes the channel changes internally.

However, unless the new bitmap is explicitly forwarded to userspace, the 
userspace component might not be aware of the bitmap changes.

> which has the beacon of the peer and handles CSA, so what happens with
> puncturing in CSA?
> 

I am thinking something like below for CSA with puncturing in Mesh,
1. Acquire the puncturing bitmap from the peer initiating the CSA action 
/ beacon frame.
2. Validate the new channel's compatibility with the new puncturing 
pattern, and apply the new channel context.
3. Forward the csa beacon/CSA action.
4. Reset the existing bitmap and apply the new bitmap to associated STAs.

I didn't take care of this in the patch series. I am planning to address 
this in the upcoming series

> Did you think about any of these questions, or are you just using me as
> a design tool? ;-)
> 

No, certainly not Johannes! 😊
I initially assumed the bandwidth would need to be decided by the driver 
  since it’s tied to packet transmission for each mesh STA— that’s kind of
how the firmware seemed to be built.

> johannes