In particular set APS_FSMCO_WLON_RESET in the right register, and do
not overwrite too much of REG_CR.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This is simpler than checking for RTL8188C && hi_pa.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This patch was being missed since rtl_chip will never match RTL8188C
if hi_pa is true.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Per the vendor driver, devices with an external PA needs limiting it's
TX power to 0x20.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This dongle was tested successfully by Andrea Merello
Reported-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Revert "rtl8xxxu: Temporarily disable 8192eu device init"

This reverts commit ccfe1e85.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Write the adjusted value back to the correct register
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This removes a bunch of if () spaghetti and re-applies the USB bus
quirks for 8188/8192 that had gotten lost.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Rather than scattering the code with #ifdefs, use the fileops
structure to hold device specific PBP values.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This was expired by the vendor driver, but we never ended up using the
backed up value.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This removes another case of ugly if () clutter
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Move setting it to rtl8723au_init_phy_bb()
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This moves the loading of the AGC table into init_phy_bb() and reduces
the if() clutter.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This should get the order right and avoid patching something that is
later overwritten.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This reduce the use of magic values a little.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The old code incorrectly wiped out bits 0-23 by mistake when setting
the RX path for 1T parts.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

No actual code flow change, but no need to warn about something that
isn't a prioblem.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

This caught a bug where too little memory was allocated for RX urbs
for parts using 24 byte RX descriptors
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Instead use tx_desc_size() to distinguish between gen1
(8723a/8192c/8188c) and gen2 (8723b/8192e) parts.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Presumably 8192eu devices do not have leds, so do not enable them.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Like the 8723bu, the vendor driver does not set FPGA0_TX_INFO for
8192eu in the init sequence.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Another flow order change to match the vendor driver.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Longer term we should switch all the chips over to use this function
instead of the random chip specific ifdef hacks.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

In order to debug 8192eu support, reorder some init code to match the
flow of the vendor driver.
Signed-off-by: NJes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

improves readability
Reviewed-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

merge copy/paste code
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

"x ? x : y" can be simplified as "x ? : y"
https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#ConditionalsReviewed-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

given this structure:
struct foo {
  struct bar {
     int baz;
  }
}

these accesses are equivalent:
(*(foo->bar)).baz
foo->bar->baz
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>