- 15 Apr, 2016 40 commits
-
-
Jes Sorensen authored
In particular set APS_FSMCO_WLON_RESET in the right register, and do not overwrite too much of REG_CR. Signed-off-by:
Jes Sorensen <Jes.Sorensen@redhat.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Jes Sorensen authored
This is simpler than checking for RTL8188C && hi_pa. Signed-off-by:
-
Jes Sorensen authored
This patch was being missed since rtl_chip will never match RTL8188C if hi_pa is true. Signed-off-by:
-
Jes Sorensen authored
Per the vendor driver, devices with an external PA needs limiting it's TX power to 0x20. Signed-off-by:
-
Jes Sorensen authored
Load the RF table in init_phy_rf(), which allows for applying device specific RF hacks in the same place. Getting rid of more ugly if () clutter. Signed-off-by:
-
Colin Ian King authored
several functions are not initializing a return status in ret resulting in garbage to be returned instead of 0 for success. Currently, the calls to these functions are not checking the return, however, it seems prudent to return the correct status in case they are to be checked at a later date. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Jes Sorensen authored
This dongle was tested successfully by Andrea Merello Reported-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
-
Jes Sorensen authored
Revert "rtl8xxxu: Temporarily disable 8192eu device init" This reverts commit ccfe1e85. Signed-off-by:
-
Jes Sorensen authored
Write the adjusted value back to the correct register Signed-off-by:
-
Jes Sorensen authored
This removes an unneeded hack for 8192eu, and allows for initializing REG_FPGA0_XAB_RF_SW_CTRL at the same point as it is done for all other parts. Signed-off-by:
-
Jes Sorensen authored
This removes a bunch of if () spaghetti and re-applies the USB bus quirks for 8188/8192 that had gotten lost. Signed-off-by:
-
Jes Sorensen authored
Rather than scattering the code with #ifdefs, use the fileops structure to hold device specific PBP values. Signed-off-by:
-
Jes Sorensen authored
This was expired by the vendor driver, but we never ended up using the backed up value. Signed-off-by:
-
Jes Sorensen authored
This removes another case of ugly if () clutter Signed-off-by:
-
Jes Sorensen authored
Move setting it to rtl8723au_init_phy_bb() Signed-off-by:
-
Jes Sorensen authored
This moves the loading of the AGC table into init_phy_bb() and reduces the if() clutter. Signed-off-by:
-
Jes Sorensen authored
This should get the order right and avoid patching something that is later overwritten. Signed-off-by:
-
Jes Sorensen authored
This reduces the if () clutter. Longer term it probably makes sense to split this between gen1 (8723au/8188cu/8192cu) and gen2 (8192eu/8723bu) devices. Signed-off-by:
-
Jes Sorensen authored
This reduce the use of magic values a little. Signed-off-by:
-
Jes Sorensen authored
The old code incorrectly wiped out bits 0-23 by mistake when setting the RX path for 1T parts. Signed-off-by:
-
Jes Sorensen authored
The 8723bu is a combo WiFi/BT dongle, and path B is not used for WiFi, so no point in calibrating it. Signed-off-by:
-
Jes Sorensen authored
No actual code flow change, but no need to warn about something that isn't a prioblem. Signed-off-by:
-
Jes Sorensen authored
This caught a bug where too little memory was allocated for RX urbs for parts using 24 byte RX descriptors Signed-off-by:
-
Jes Sorensen authored
This shouldn't affect little endian system, but may have prevented the driver working on big endian systems for devices with the larger 24 byte RX descriptors. Signed-off-by:
-
Jes Sorensen authored
Instead use tx_desc_size() to distinguish between gen1 (8723a/8192c/8188c) and gen2 (8723b/8192e) parts. Signed-off-by:
-
Jes Sorensen authored
8192eu is a 2T part, so setting TX power for path A only, as done by rtl8723bu_set_tx_power() is not sufficient. Signed-off-by:
-
Jes Sorensen authored
Presumably 8192eu devices do not have leds, so do not enable them. Signed-off-by:
-
Jes Sorensen authored
Like the 8723bu, the vendor driver does not set FPGA0_TX_INFO for 8192eu in the init sequence. Signed-off-by:
-
Jes Sorensen authored
The vendor driver does not set REG_PBP on 8192eu. Whether this is due to the device not supporting it or simply an oversight in the vendor driver is not clear. Signed-off-by:
-
Jes Sorensen authored
Another flow order change to match the vendor driver. Signed-off-by:
-
Jes Sorensen authored
Longer term we should switch all the chips over to use this function instead of the random chip specific ifdef hacks. Signed-off-by:
-
Jes Sorensen authored
This further reorganizes the init code flow to match that of the 8192eu vendor driver. This helps diffing the register write log against that of the vendor driver. Signed-off-by:
-
Jes Sorensen authored
In order to debug 8192eu support, reorder some init code to match the flow of the vendor driver. Signed-off-by:
-
Andreas Fenkart authored
after factoring out mwifiex_cancel_pending_scan_cmd the function is not called outside of cmdevt file moved function to head of file to avoid forward declaration, also moved mwifiex_recycle_cmd_node since they are very similar Signed-off-by:
Andreas Fenkart <afenkart@gmail.com> Signed-off-by:
-
Andreas Fenkart authored
Releasing the scan_pending lock in mwifiex_check_next_scan_command introduces a short window where pending scan commands can be removed or added before removing them all in mwifiex_cancel_pending_scan_cmd. I think this is safe, since the worst thing to happen is that a pending scan cmd is removed by the command handler. Adding new scan commands is not possible while one is pending, see scan_processing flag. Since all commands are removed from the queue anyway, we don't care if some commands are removed by a different code path earlier, the final state remains the same. I assume, that the critical section needed for the check has been extended over clearing the pending scan queue out of convenience. The lock was already held and releasing it and grab it again was just more work. It doesn't seem to be necessary because of concurrency. Signed-off-by:
-
Andreas Fenkart authored
improves readability Reviewed-by:
Julian Calaby <julian.calaby@gmail.com> Signed-off-by:
-
Andreas Fenkart authored
merge copy/paste code Signed-off-by:
-
Andreas Fenkart authored
"x ? x : y" can be simplified as "x ? : y" https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#ConditionalsReviewed-by:
-
Andreas Fenkart authored
Signed-off-by:
-
Andreas Fenkart authored
given this structure: struct foo { struct bar { int baz; } } these accesses are equivalent: (*(foo->bar)).baz foo->bar->baz Signed-off-by:
-
