public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Felix Fietkau <nbd@nbd.name>, linux-wireless@vger.kernel.org
Cc: quic_adisi@quicinc.com, quic_periyasa@quicinc.com,
	 ath12k@lists.infradead.org
Subject: Re: [RFC v3 8/8] wifi: mac80211: add wiphy radio assignment and validation
Date: Fri, 07 Jun 2024 12:12:13 +0200	[thread overview]
Message-ID: <8cac5465a87e2829d4c617995a19d3f4deba2ed8.camel@sipsolutions.net> (raw)
In-Reply-To: <c5abf1ae-bdda-42b2-95c0-9b1c39659bbd@nbd.name>

On Fri, 2024-06-07 at 11:53 +0200, Felix Fietkau wrote:

> > struct wiphy_radio *wiphy_get_radio(struct wiphy *wiphy, ... *chandef);
> 
> I didn't add such a helper, in case we get hardware where multiple 
> radios support the same band. That's why ieee80211_find_available_radio 
> loops over all radios until it finds one that matches both the freq 
> range and the ifcomb constraints.

Ah, fair.

Thinking more about the "whole chandef" thing, I think I want to have a
check in cfg80211 somewhere that ensures you don't split up ranges that
could be used for a wider channel?

Say (for a stupid example) you have a device that (only) supports
channels 36-40:

 * 5180
 * 5200

but now you say it has two radios:

 * radio 1 ranges: 5170-5190
 * radio 2 ranges: 5190-5210

Now you can't use 40 MHz... but nothing will actually really prevent it.

Obviously this is a totally useless case, so I'd argue we should just
check during wiphy registration that you don't split the channel list in
this way with multiple radios?

Even on the potential Qualcomm 5 GHz low/mid/high split radios you'd
have gaps between the channels (e.g. no channel 80, no channel 148), so
it feels like you should always be able to split it in a way that the
radio range boundaries don't land between two adjacent channels in the
channel array.

Not sure how to implement such a check best, probably easiest to find
all non-adjacent channels first:

 
 - go over bands
   - ensure channels are sorted by increasing frequency
     (not sure we do that today? but every driver probably does)
   - find adjacent channels:
     - while more channels:
       - start_freq = current channel's freq - 10
       - end_freq = current channel's freq + 10
       - while current channel's freq == end_freq - 10:
         - go to next channel
       - check all radio's ranges cover this full or not at all
         (neither start nor end of a range falls into the calculated
          [start_freq, end_freq) interval)

or something like that?

(Also some docs on this I guess!)

johannes

      reply	other threads:[~2024-06-07 10:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06 18:07 [RFC v3 0/8] cfg80211/mac80211: support defining multiple radios per wiphy Felix Fietkau
2024-06-06 18:07 ` [RFC v3 1/8] wifi: nl80211: split helper function from nl80211_put_iface_combinations Felix Fietkau
2024-06-06 18:07 ` [RFC v3 2/8] wifi: cfg80211: add support for advertising multiple radios belonging to a wiphy Felix Fietkau
2024-06-07  9:24   ` Johannes Berg
2024-06-07 10:00     ` Felix Fietkau
2024-06-06 18:07 ` [RFC v3 3/8] wifi: cfg80211: extend interface combination check for multi-radio Felix Fietkau
2024-06-07  9:32   ` Johannes Berg
2024-06-07 12:36     ` Felix Fietkau
2024-06-06 18:07 ` [RFC v3 4/8] wifi: mac80211: add support for DFS with multiple radios Felix Fietkau
2024-06-07  4:25   ` Karthikeyan Periyasamy
2024-06-07  4:35     ` Felix Fietkau
2024-06-07  4:54       ` Karthikeyan Periyasamy
2024-06-07  5:03         ` Felix Fietkau
2024-06-07  6:45           ` Karthikeyan Periyasamy
2024-06-07  8:16             ` Felix Fietkau
2024-06-07  8:54               ` Karthikeyan Periyasamy
2024-06-07  9:00                 ` Felix Fietkau
2024-06-12 14:23   ` Karthikeyan Periyasamy
2024-06-12 14:29     ` Felix Fietkau
2024-06-06 18:07 ` [RFC v3 5/8] wifi: mac80211: add radio index to ieee80211_chanctx_conf Felix Fietkau
2024-06-06 18:07 ` [RFC v3 6/8] wifi: mac80211: extend ifcomb check functions for multi-radio Felix Fietkau
2024-06-07  4:45   ` Karthikeyan Periyasamy
2024-06-07  4:49     ` Felix Fietkau
2024-06-07  9:22   ` Karthikeyan Periyasamy
2024-06-07 10:07   ` Karthikeyan Periyasamy
2024-06-07 10:22     ` Felix Fietkau
2024-06-07 10:53       ` Karthikeyan Periyasamy
2024-06-07 11:04         ` Felix Fietkau
2024-06-12 12:05           ` Johannes Berg
2024-06-12 12:21             ` Felix Fietkau
2024-06-06 18:07 ` [RFC v3 7/8] wifi: mac80211: move code in ieee80211_link_reserve_chanctx to a helper Felix Fietkau
2024-06-06 18:07 ` [RFC v3 8/8] wifi: mac80211: add wiphy radio assignment and validation Felix Fietkau
2024-06-07  9:44   ` Johannes Berg
2024-06-07  9:53     ` Felix Fietkau
2024-06-07 10:12       ` Johannes Berg [this message]

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=8cac5465a87e2829d4c617995a19d3f4deba2ed8.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ath12k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nbd@nbd.name \
    --cc=quic_adisi@quicinc.com \
    --cc=quic_periyasa@quicinc.com \
    /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