Fix incorrect abs macro #739
Merged
Conversation
This file contains 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
Wrong abs calculation can cause incorrect channel width in vht negotiation
|
It should be a good fix, Thanks! |
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.
I noticed there is an issue during negotiate vht channels. If both the ap and station support 160mhz, only channels 36,40,44,48,100,104,108,112 can successfully negotiate as 160mhz. If the ap is configured as channels 52,56,60,64,116,120,124,128, the result is 20mhz.
It appears the incorrect
absmacro cause the vht negotiate think certain channel is 80+80 which should be 160. The intel cards don't support 80+80 and thus the driver treat them as 20mhz.The fix is to correct the
absmacro and also use__builtin_absif available