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.
Version information: 20140812_rtl8192EU_linux_v4.3.1.1_11320
2014-08-12
version 4.3.1.1_11320
Source:
ftp://files.dlink.com.au/products/DWA-131/REV_E/Drivers/DWA-131_Linux_driver_v4.3.1.1.zip
This version does not currently work on newer kernels, but it does
contain USB ID 2001:3319, which a lot of other repos in GitHub does not.
