RDKBWIFI-517: Fix 2.4GHz 40MHz secondary channel in get_on_channel_sc…#1274
Open
dkyncu wants to merge 1 commit into
Open
RDKBWIFI-517: Fix 2.4GHz 40MHz secondary channel in get_on_channel_sc…#1274dkyncu wants to merge 1 commit into
dkyncu wants to merge 1 commit into
Conversation
…an_list
The channels_2g_40_mhz[] table in get_on_channel_scan_list() used a +/-2
channel offset for the HT40 secondary channel (e.g. primary 1 -> {1,3}). In
2.4GHz the channel numbers are spaced 5 MHz apart, so the two non overlapping
20MHz halves of a 40MHz bond are 20 MHz = 4 channel numbers apart
(secondary = primary +/-4). {1,3} are only 10 MHz apart and overlap, which is
not a valid 40MHz pair. The 5GHz and 6GHz tables in the same function already
use the correct +4 spacing.
With the wrong offset, get_on_channel_scan_list() returned an overlapping
sub channel for every 2.4GHz 40MHz primary, so consumers that check the
sub channels against an allowed list (e.g. channel scan, ACS) could not deploy
a 2.4GHz 40MHz channel and fell back to 20MHz.
Correct the table to the standard 2.4GHz HT40 pairs (1+5, 6+10, 11+7, ...).
Signed-off-by: Durmus Koyuncu <durmus.kyncu.kd@gmail.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes 2.4GHz HT40 (40MHz) on-channel scan subchannel selection in get_on_channel_scan_list() by correcting the secondary-channel spacing from ±2 channels to the correct ±4 channels (20MHz) separation, aligning behavior with the existing 5GHz/6GHz tables and preventing invalid overlapping 40MHz pairs.
Changes:
- Update the 2.4GHz 40MHz primary/secondary channel mapping table to use ±4 channel offsets (e.g., 1↔5, 6↔10, 11↔7).
- Ensure on-channel scan consumers (e.g., channel scan/ACS) receive valid 2.4GHz HT40 subchannels rather than overlapping 10MHz-apart pairs.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…an_list
The channels_2g_40_mhz[] table in get_on_channel_scan_list() used a +/-2 channel offset for the HT40 secondary channel (e.g. primary 1 -> {1,3}). In 2.4GHz the channel numbers are spaced 5 MHz apart, so the two non overlapping 20MHz halves of a 40MHz bond are 20 MHz = 4 channel numbers apart (secondary = primary +/-4). {1,3} are only 10 MHz apart and overlap, which is not a valid 40MHz pair. The 5GHz and 6GHz tables in the same function already use the correct +4 spacing.
With the wrong offset, get_on_channel_scan_list() returned an overlapping sub channel for every 2.4GHz 40MHz primary, so consumers that check the sub channels against an allowed list (e.g. channel scan, ACS) could not deploy a 2.4GHz 40MHz channel and fell back to 20MHz.
Correct the table to the standard 2.4GHz HT40 pairs (1+5, 6+10, 11+7, ...).