public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@nbd.name>
To: Johannes Berg <johannes@sipsolutions.net>,
	Karthikeyan Periyasamy <quic_periyasa@quicinc.com>,
	linux-wireless@vger.kernel.org
Cc: quic_adisi@quicinc.com, ath12k@lists.infradead.org
Subject: Re: [RFC v3 6/8] wifi: mac80211: extend ifcomb check functions for multi-radio
Date: Wed, 12 Jun 2024 14:21:24 +0200	[thread overview]
Message-ID: <91704e4c-b43c-4efc-b78d-e67abc35128d@nbd.name> (raw)
In-Reply-To: <fa7c2aeef854f89eeb03a01a21a8d511417c92b6.camel@sipsolutions.net>

On 12.06.24 14:05, Johannes Berg wrote:
> On Fri, 2024-06-07 at 13:04 +0200, Felix Fietkau wrote:
>> > > 
>> > > Use the sum of the number of interfaces from each radio instead of the 
>> > > maximum.
>> > 
>> > Oh, then legacy user have misconception of the global interfaces
>> > advertised and try to fail for the allowed limits.
>> 
>> Sure, but that might be an issue either way until user space is updated 
>> and users start looking at the per-radio ifcomb data.
> 
> I'm kind of with Karthikeyan here - this could be understood as a
> regression, since you're now telling userspace something you can't
> actually do.

Well, we can actually do it, just with some extra restrictions - i.e. 
the interfaces we create need to be spread across radios to match the 
per-radio limits.

>> The global data is simply not enough to describe the details of the 
>> radio split.
> 
> Obviously, but that doesn't mean the global data as advertised in the
> existing attributes must be *wrong*. It could be a subset, and the
> superset data is only available to new implementations.
So you'd prefer something like picking one radio and advertising its 
limits instead?

- Felix

  reply	other threads:[~2024-06-12 12:21 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 [this message]
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

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=91704e4c-b43c-4efc-b78d-e67abc35128d@nbd.name \
    --to=nbd@nbd.name \
    --cc=ath12k@lists.infradead.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --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