From: Denis Kenzior <denkenz@gmail.com>
To: James Prestwood <prestwoj@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 05/10] band: add APIs to generate a chandef from frequency
Date: Wed, 28 Dec 2022 15:10:05 -0600 [thread overview]
Message-ID: <c1ace2ab-2ffe-ab37-cd33-0f9f0d6c2807@gmail.com> (raw)
In-Reply-To: <ca84d3ce71bf2f17360f63303bbca1b841eb36cc.camel@gmail.com>
Hi James,
> We still need to support 20Mhz since there is this distinction between
> 20MHz HT and 20Mhz no-HT. If only 20MHz HT is supported we should pick
> that rather than the non-HT width.
Hmm, but there's no difference in operating class between 20HT and 20NoHT. So
this could be done post-factum, no?
>
> So ap.c just tries to pick the best chandef so in theory we could fall
> back to non-HT and this wouldn't be totally unexpected (from the users
> perspective). The problem is we would then need to disable HT in ap.c
> if we fell back to non-HT.
Something like if ap->chandef.channel_width == 20HT && !ap->supports_ht -> set
channel_width appropriately.
>
> Since I may just remove band_freq_to_chandef() entirely I might instead
> keep the -ENOENT return and fall back inside ap.c itself. Then I don't
> have to check chandef->channel_width after a successful return and we
> know this will always return an HT chandef, or fail.
>
Or do that. Or pass in the ht capability to band_freq_to_chandef() and let it
figure it out.
Regards,
-Denis
next prev parent reply other threads:[~2022-12-28 21:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 21:43 [PATCH 01/10] ap: make supported rates a common builder James Prestwood
2022-12-20 21:43 ` [PATCH 02/10] nl80211util: parse additional channel restriction flags James Prestwood
2022-12-20 21:43 ` [PATCH 03/10] band: add ampdu_params value James Prestwood
2022-12-20 21:43 ` [PATCH 04/10] wiphy: add getter for HT capabilities James Prestwood
2022-12-27 17:22 ` Denis Kenzior
2022-12-20 21:43 ` [PATCH 05/10] band: add APIs to generate a chandef from frequency James Prestwood
2022-12-27 18:07 ` Denis Kenzior
2022-12-28 19:50 ` James Prestwood
2022-12-28 21:10 ` Denis Kenzior [this message]
2022-12-20 21:43 ` [PATCH 06/10] band: add band_chandef_width_to_string James Prestwood
2022-12-27 17:33 ` Denis Kenzior
2022-12-20 21:43 ` [PATCH 07/10] wiphy: add wiphy_supports_uapsd James Prestwood
2022-12-20 21:43 ` [PATCH 08/10] ap: include WMM parameter IE James Prestwood
2022-12-27 18:09 ` Denis Kenzior
2022-12-20 21:43 ` [PATCH 09/10] ap: build HT Capabilities/Operation elements James Prestwood
2022-12-20 21:43 ` [PATCH 10/10] ap: generate chandef for starting AP James Prestwood
2022-12-27 16:59 ` [PATCH 01/10] ap: make supported rates a common builder Denis Kenzior
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=c1ace2ab-2ffe-ab37-cd33-0f9f0d6c2807@gmail.com \
--to=denkenz@gmail.com \
--cc=iwd@lists.linux.dev \
--cc=prestwoj@gmail.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;
as well as URLs for NNTP newsgroup(s).