Re: [wireless-next v2 2/4] wifi: mac80211: support initialising an S1G short beaconing BSS

[Johannes Berg <johannes@sipsolutions.net>]

On Wed, 2025-07-16 at 19:01 +1000, Lachlan Hodges wrote:
> An interface can't be modified such that we can disable short beaconing
> without tearing it down.

OK, that's fair. No objection to that, just wanted to clarify if that
was what you intended.

> > This should probably be on the cfg80211 patch, but now that I'm writing
> > here ... If there is no new short beacon update cannot currently be set
> > to true, I think? And also, right now by the policy you can't set the
> > long_beacon_interval == 1 from userspace, but what if you actively want
> > to _remove_ the short beacon entirely?
> > 
> 
> I initially did think so that this should be in a cfg80211 targetted
> patch but since cfg.c since within mac80211 I did such. Can do either.

Oh, sorry, what I said was confusing. I meant I should be _commenting_
on the cfg80211 patch instead (about the logic of being able to remove
the short beacon or not). But you clarified that above.

> So you are correct, It's not legal to disable short beaconing without
> tearing the interface down (as mentioned above). Thats why within
> ieee80211_change_beacon() we check if we are short beaconing first
> and if theres an update proceed with said update. This function should
> really just be setting the new pointers and discarding the old pointers
> if they exist i.e during an update. 

Right, makes sense.

> Yea.. this seems to be a case of me stealing the beacon change code...
> :).

OK, I don't know what that code does off-hand, maybe there we have some
other things that don't always need to change.

> static int
> ieee80211_set_s1g_short_beacon(struct ieee80211_sub_if_data *sdata,
> 			       struct cfg80211_s1g_short_beacon *params,
> 			       struct ieee80211_link_data *link)
> {
...

> 	/* Memory layout: | struct | head | tail | */
> 	new->short_head = ((u8 *)new) + sizeof(*new);

You probably don't need the extra () around "(u8 *)new".

> seems more robust, where we simply update the new beacon given
> the parameters and discard the old, else if theres no update
> we do nothing.

Yeah, that looks good to me.

johannes