linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Cc: linux-wireless@vger.kernel.org, arien.judge@morsemicro.com
Subject: Re: [RFC 2/5] wifi: mac80211: support initialising an S1G short beaconing BSS
Date: Mon, 14 Jul 2025 15:03:44 +0200	[thread overview]
Message-ID: <3bf402034b4a975a603e22b8acf9c8974c47c237.camel@sipsolutions.net> (raw)
In-Reply-To: <20250714051403.597090-3-lachlan.hodges@morsemicro.com> (sfid-20250714_071452_254485_0C545169)

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.


> +		if (params->s1g_short_beacon.short_interval) {
> +			/*
> +			 * IEEE80211-2024 11.1.3.10.2:
> +			 * beacon_int = n * short_beacon_int where n is a
> +			 * positive integer and represents the short beacon
> +			 * period which is the number of short beacons
> +			 * transmitted per long beacon.
> +			 */
> +			if (do_div(beacon_interval,
> +				   params->s1g_short_beacon.short_interval)) {

Again not sure I understand the use of do_div, and wouldn't it be enough
for cfg80211 to check?

johannes

  reply	other threads:[~2025-07-14 13:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14  5:13 [RFC 0/5] wifi: S1G short beacon support Lachlan Hodges
2025-07-14  5:13 ` [RFC 1/5] wifi: cfg80211: support configuring an S1G short beaconing BSS Lachlan Hodges
2025-07-14 13:00   ` Johannes Berg
2025-07-15  9:12     ` Lachlan Hodges
2025-07-15  9:18       ` Johannes Berg
2025-07-15  9:23         ` Johannes Berg
2025-07-14  5:14 ` [RFC 2/5] wifi: mac80211: support initialising " Lachlan Hodges
2025-07-14 13:03   ` Johannes Berg [this message]
2025-07-15  9:15     ` Lachlan Hodges
2025-07-14  5:14 ` [RFC 3/5] wifi: mac80211: configure power save for " Lachlan Hodges
2025-07-14 13:07   ` Johannes Berg
2025-07-14  5:14 ` [RFC 4/5] wifi: mac80211: support returning the S1G short beacon skb Lachlan Hodges
2025-07-14  5:14 ` [RFC 5/5] wifi: mac80211_hwsim: add S1G short beacon support Lachlan Hodges
2025-07-14 12:50 ` [RFC 0/5] wifi: " Johannes Berg
2025-07-15  9:07   ` Lachlan Hodges

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3bf402034b4a975a603e22b8acf9c8974c47c237.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=arien.judge@morsemicro.com \
    --cc=lachlan.hodges@morsemicro.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).