Search Linux Wireless

Re: [RFC 2/5] wifi: mac80211: support initialising an S1G short beaconing BSS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 14, 2025 at 03:03:44PM +0200, Johannes Berg wrote:
> On Mon, 2025-07-14 at 15:14 +1000, Lachlan Hodges wrote:
> > 
> > @@ -758,6 +760,16 @@ struct ieee80211_parsed_tpe {
> >   *	be updated to 1, even if bss_param_ch_cnt didn't change. This allows
> >   *	the link to know that it heard the latest value from its own beacon
> >   *	(as opposed to hearing its value from another link's beacon).
> > + * @s1g_short_beaconing: determines if short beaconing is enabled for an S1G
> > + *	BSS.
> > + * @s1g_short_beacon_int: short beacon interval in TUs. When short beaconing is
> > + *	enabled beacon transmission times are computed using this value as
> > + *	opposed to beacon_int as per IEEE80211-2024 11.1.2.1.
> > + * @s1g_short_beacon_dtim_period: number of short beacon intervals that elapse
> > + *	between each beacon with a TIM element whose DTIM count is 0. When
> > + *	short beaconing is enabled, this value is used as opposed to
> > + *	dtim_period as per IEEE80211-2024 9.4.2.5.1.
> > + * @s1g_short_beacon_period: number of short beacons sent per long beacon.
> >   */
> >  struct ieee80211_bss_conf {
> >  	struct ieee80211_vif *vif;
> > @@ -857,6 +869,11 @@ struct ieee80211_bss_conf {
> >  
> >  	u8 bss_param_ch_cnt;
> >  	u8 bss_param_ch_cnt_link_id;
> > +
> > +	bool s1g_short_beaconing;
> > +	u16 s1g_short_beacon_int;
> > +	u8 s1g_short_beacon_dtim_period;
> > +	u16 s1g_short_beacon_period;
> 
> Does the driver even need to know? For hwsim this is just additional
> complexity - mac80211 could set the beacon interval to the short beacon
> interval, and simply return the long beacon every
> "s1g_short_beacon_period" (which perhaps should be called
> "s1g_long_beacon_period")?
> 
> But depends on how your driver works I guess. Given these parameters
> though, you can't really offload it entirely either since there's no way
> to get a short beacon template now.

So this is something I forgot to mention in the cover letter, since yes
it simply adds code bloat (mentioned here and in the other patch). I
guess my intention was the "follow the standard" but maybe a bit too
much :). Without these new parameters the patchset is much leaner
and probably makes more sense anyway since at the end of the day,
the beacon interval is still the beacon interval and same for the
DTIM period. New patchset will exclude these new parameters, which
definitely cleans up much of the code.

lachlan.




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux