From: Johannes Berg <johannes@sipsolutions.net>
To: Wen Gong <quic_wgong@quicinc.com>, linux-wireless@vger.kernel.org
Cc: ath12k@lists.infradead.org, quic_rkaliapp@quicinc.com
Subject: Re: [PATCH 61/76] wifi: nl80211: add EML/MLD capabilities to per-iftype capabilities
Date: Fri, 11 Aug 2023 11:08:58 +0200 [thread overview]
Message-ID: <8627bb8a3dddc33be7f1f97f30fc0f716328ff81.camel@sipsolutions.net> (raw)
In-Reply-To: <cc6b83eb-ac30-34fc-4827-290a9ae25378@quicinc.com>
On Fri, 2023-08-11 at 17:05 +0800, Wen Gong wrote:
> On 8/11/2023 5:03 PM, Johannes Berg wrote:
> > On Fri, 2023-08-11 at 11:51 +0800, Wen Gong wrote:
> > > Now there are many nl80211_band such as NL80211_BAND_2GHZ/
> > > NL80211_BAND_5GHZ/NL80211_BAND_6GHZ... In the same interface, if some bands
> > > support EML, and other bands not support EML, then how to handler this
> > > case?
> > But ... these are MLD capabilities, not of the (associated) STA?
> Yes, I know it.
Then you can't honestly be suggesting we move "MLD capa and ops" into
per-band, no?
> > So not sure how that would make sense? What would you even _do_ with
> > that?
> I think another change is not move "u16 eml_capabilities", and only add
> a new
> field "u16 eml_supp_bands" together with the "u16 eml_capabilities", the
> eml_supp_bands is filled with the bit map of enum nl80211_band. Is that OK?
>
And again, what would you do with it? Not advertise EML when you have
selected links that are not in the map? And if the links change
dynamically in the future? You'd probably need a bunch of validation for
that.
And usually you'd probably always connect to all the bands?
I really don't get it.
Btw this is all client - so your client implementation can just not send
the EML action frame (forgot the name right now) when the currently
active links are not compatible.
johannes
--
ath12k mailing list
ath12k@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/ath12k
next prev parent reply other threads:[~2023-08-11 9:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220713094502.163926-1-johannes@sipsolutions.net>
[not found] ` <20220713114426.4dfc9ebd0461.Ice7b841051cfeb23da17bb2caa0e45191b34c4db@changeid>
2023-08-11 3:51 ` [PATCH 61/76] wifi: nl80211: add EML/MLD capabilities to per-iftype capabilities Wen Gong
2023-08-11 9:03 ` Johannes Berg
2023-08-11 9:05 ` Wen Gong
2023-08-11 9:08 ` Johannes Berg [this message]
2023-08-11 9:24 ` Wen Gong
2023-08-11 9:27 ` Johannes Berg
2023-08-11 9:54 ` Wen Gong
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=8627bb8a3dddc33be7f1f97f30fc0f716328ff81.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ath12k@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_rkaliapp@quicinc.com \
--cc=quic_wgong@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