-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PW_SID:706060] [01/10] ap: make supported rates a common builder. #208
base: workflow
Are you sure you want to change the base?
Conversation
This is taken care of by the individual cache items and if none exist, tar fails.
The supported rates IE was being built in two places. This makes that code common. Unfortunately it needs to support both an ie builder and using a pointer directly which is why it only builds the contents of the IE and the caller must set the type/length.
This is the last bit of information the kernel exposes about the hardware's HT capabilities.
This adds some additional parsing to obtain the AMPDU parameter byte as well as wiphy_get_ht_capabilities() which returns the complete IE (combining the 3 separate kernel attributes).
For AP mode its convenient for IWD to choose an appropriate channel definition rather than require the user provide very low level parameters such as channel width, center1 frequency etc. This adds two new APIs to generate a channel definition, one for legacy and one for HT. The legacy API is very simple and chooses the first matching operating class using 20Mhz channel widths. The HT API is a bit more complex since it has to take into account 40MHz and check any channel restrictions. If an operating class is found that is supported/not restricted it is marked as 'best' until a better one is found. In this case 'better' is a larger channel width. Since this is HT only 20mhz and 40mhz widths are checked.
The WMM parameter IE is expected by the linux kernel for any AP supporting HT/VHT etc. IWD won't actually use WMM and its not clear exactly why the kernel uses this restriction, but regardless it must be included to support HT.
If supported this will include the HT capabilities and HT operations elements in beacons/probes. Some shortcuts were taken here since not all the information is currently parsed from the hardware. Namely the HT operation element does not include the basic MCS set. Still, this will at least show stations that the AP is capable of more than just basic rates. The builders themselves are structured similar to the basic rates builder where they build only the contents and return the length. The caller must set the type/length manually. This is to support the two use cases of using with an IE builder vs direct pointer.
To include HT support a chandef needs to be created for whatever frequency is being used. This allows IWD to provide a secondary channel to the kernel in the case of 40MHz operation. Now the AP will generate a chandef when starting based on the channel set in the user profile (or default).
Fetch PR Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Output:
|
Fetch PR GitLint Output:
Make Distcheck Build - Configure Make Check Make Check w/Valgrind Incremental Build with patches Output:
Autotest Runner Output:
Clang Build |
402b769
to
27a5152
Compare
c931b28
to
4967dfb
Compare
4967dfb
to
aed50bd
Compare
1914242
to
5b2d21d
Compare
abf12d2
to
fd6f61b
Compare
326217a
to
0e84c68
Compare
9857f8e
to
8991f76
Compare
1632776
to
d9267df
Compare
aada677
to
1163d8b
Compare
cd38a46
to
a84ea46
Compare
9ef1a07
to
b2ed861
Compare
b2ed861
to
4dff1fb
Compare
The supported rates IE was being built in two places. This makes that
code common. Unfortunately it needs to support both an ie builder
and using a pointer directly which is why it only builds the contents
of the IE and the caller must set the type/length.
src/ap.c | 68 +++++++++++++++++++++++++-------------------------------
1 file changed, 30 insertions(+), 38 deletions(-)