This patch switches to <linux/ieee80211.h> and <net/cfg80211.h> and
deletes a lot of duplicate definitions plus many unused ones.
rtw_ieee80211_hdr_3addr_qos is duplicate of ieee80211_qos_hdr.
rtw_ieee80211_spectrum_mgmt_actioncode is a duplication of ieee80211_spectrum_mgmt_actioncode
rtw_ieee80211_hdr_3addr is duplicate of ieee80211_hdr_3addr.
rtw_ieee80211_hdr is duplicate of ieee80211_hdr
rtw_ieee80211s_hdr is duplicate of ieee80211s_hdr
rtw_ieee80211_rann_ie is duplicate of ieee80211_rann_ie
from include/linux/ieee80211.h.
Link: https://lore.kernel.org/r/20200906133236.556427-1-insafonov@gmail.com
Link: https://lore.kernel.org/r/20200609194848.166130-1-pterjan@google.com
Also port
5cd8396540b5f7ef7c3ac499e967dd4deb8e9930
bbfe286b07d8282f4957dee692e85b3bd60de770
d87f574d6923c546e7d0f75ce0581436376b98a6
36eb7d108e8de3097f373eb8629d8739d4fa3e74
1b9e6df5169b36b3242e2e28c39f9bbfc01863e8
d94971aa97670d400371baef5d9d5cf6dc8ea2b5
Remove empty functions from ieee80211.h
Use values from linux/ieee80211.h
port 12a17d72f7948148b80c0dfa72ea983da33464ba
port a9d8763889737b7e0f83956e093bd48190876044
port 872cfb096d3a009709b56f23f5280a359bbe58e2
port a4bc0fa9ec51008bb494943ec98b4ad836e3a216
port 13e00f8ebded278a7887d98ad65ceabc24f3776a
Using eth_broadcast_addr() to assign broadcast address instead
of copying from an array that contains the all-ones broadcast
address
Port 78adf574c969c14a470b686af8d6bd7e1dcf142b
Port 3b0a4a1bdb0f6348dba797a0fa1cf161f5639ded
Port 44c26bec861476f89ac5aee0bb19df128a42543b
Link: https://lore.kernel.org/r/20210616081243.2511663-4-yangyingliang@huawei.com
The values defined in enum WIFI_FRAME_SUBTYPE are the same the #define
IEEE80211_STYPE_xxx from <linux/ieee80211.h>.
Port 33ed2b7079f6c38abce6abbaf1e6be4edad919d8
ones at linux/ieee80211.h.
port 69fea2b4e59c52844cf5196c9c81157792d194fb
port 6ee9e6ee5c486f68e424185e133984d0a6ae662c
port f179515da9780c4cd37bee76c3cbb6f7364451d6
port aaa0bc19facf31426ca57267edc681a42dbd1ee1
port 99bb776980eeb231558a6ede0a1dd8d1a6e8ec0c
port 00f0b682841337c4d2e7dd2e75d86acb6b7ce2d8
port fc41e9618fc65bea5d615d487ca7de3b0e1110bc
port 3359e2927b321c635d9529bab1f087ac39c82227
port 38caee0abe9db1db387e7bea60a980eda22e9fa6
port b05cc3a9156b6b674904016d9c213e71c149f4c2
The index for r8188eu's vendor-specific control requests is not used.
Remove the index parameter from usbctrl_vendorreq and pass index 0 to
usb_control_msg.
This patch is an adaptation of commit 3d0be94f62fd ("staging: rtl8188eu:
ctrl vendor req index is not used") for the new r8188eu driver.
Link: https://lore.kernel.org/r/20210818200041.10870-2-martin@kaiser.cx
At the moment, usbctrl_vendorreq's requesttype parameter must be set to
1 for reading and 0 for writing. It's then converted to the actual
bmRequestType for the USB control request. We can simplify the code and
avoid this conversion if the caller passes the actual bmRequestType.
This patch is an adaptation of commit 788fde031027 ("staging: rtl8188eu:
use actual request type as parameter") for the new r8188eu driver.
Link: https://lore.kernel.org/r/20210821164859.4351-3-martin@kaiser.cx
The bRequest value for the vendor specific control requests sent by this
driver is always 0x05. Replace the function parameter with the define from
usb_ops.h.
This patch is an adaptation of commit eeb4661560ff ("staging: rtl8188eu:
ctrl vendor req value is always 0x05") for the new r8188eu driver.
Link: https://lore.kernel.org/r/20210818200041.10870-1-martin@kaiser.cx
Convert all rtw_zvmalloc calls within the driver to use the existing
kernel vzalloc function, which has the same semantics. Also rewrite the
two places where it is mentioned in comments to say vzalloc, and remove
the redundant cast to struct adapter * in ./os_dep/usb_intf.c as vzalloc
returns void *.
The reason for the conversion is that rtw_zvmalloc is just a
preprocessor definition for _rtw_zvmalloc which itself is just an inline
wrapper around vmalloc which then zeroes the memory out. As vzalloc does
the same thing via usage of __GFP_ZERO, this code is redundant and can
subsequently be removed.
Link: https://lore.kernel.org/r/20210818234853.208448-5-phil@philpotter.co.uk
Turns out these devices can serve as really decent access points.
Adding txpower control info as well. See my other PR.
This is in a separate PR because the readme instructed to do so.
Update README.md
Move my lines more to the bottom
Implement simple transmit power boost and fixed setting
Source: 80b9bc47b3
Turns out the "higher levels" of this driver are not actually able to affect the device's physical power output, like via cfg80211, yet.
After some extensive testing I finally found the code responsible for setting the device's power and added some compile-time
tunables to influence it. For example here we give the transmit power index a tiny boost of two, which can be changed by the user via the source.
This is as far as my skills go so if you want to try and make this accessible to iw and iwconfig please give it a go.
Note that this will take an index between 1 (min power the device can put out) and 63 (max power the device can put out). I have no idea what these values actually translate to in dBm, but setting the override to max, 63, on my rtl card really gave range a boost.
Add AP and TXPOWER CONTROL info
Turns out these devices can serve as really decent access points.
Adding txpower control info as well. See my other PR.
This is in a separate PR because the readme instructed to do so.
Update README.md
Move my lines more to the bottom
Implement simple transmit power boost and fixed setting
Source: 80b9bc47b3
Turns out the "higher levels" of this driver are not actually able to affect the device's physical power output, like via cfg80211, yet.
After some extensive testing I finally found the code responsible for setting the device's power and added some compile-time
tunables to influence it. For example here we give the transmit power index a tiny boost of two, which can be changed by the user via the source.
This is as far as my skills go so if you want to try and make this accessible to iw and iwconfig please give it a go.
Note that this will take an index between 1 (min power the device can put out) and 63 (max power the device can put out). I have no idea what these values actually translate to in dBm, but setting the override to max, 63, on my rtl card really gave range a boost.
Add AP and TXPOWER CONTROL info
Turns out these devices can serve as really decent access points.
Adding txpower control info as well. See my other PR.
This is in a separate PR because the readme instructed to do so.
Update README.md
Move my lines more to the bottom
Implement simple transmit power boost and fixed setting
Source: 80b9bc47b3
Turns out the "higher levels" of this driver are not actually able to affect the device's physical power output, like via cfg80211, yet.
After some extensive testing I finally found the code responsible for setting the device's power and added some compile-time
tunables to influence it. For example here we give the transmit power index a tiny boost of two, which can be changed by the user via the source.
This is as far as my skills go so if you want to try and make this accessible to iw and iwconfig please give it a go.
Note that this will take an index between 1 (min power the device can put out) and 63 (max power the device can put out). I have no idea what these values actually translate to in dBm, but setting the override to max, 63, on my rtl card really gave range a boost.
