rtl8187se nees extra parameters to be read from the eeprom.
This patch adds support for it
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

configuration of carbus-related registers is different for
rtl8187se.
Introduce a dedicated function that does it for all cards in the
proper way
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds tx queue mapping for rtl8187se and a long comment
block about their usages.
It adapts the TX function to use that map and it sets properly
the TX descriptor rtl8187se-only fields
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

MAR registers are not present in rtl8187se, and attempting to
write to them must be avoided
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch introduces two dedicated functions for enabling and
disabling ints.
Support for rtl8187se is also added to them
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rtl8187se has more queues and different ISR flags.
This patch adds a separated ISR handler for rtl8187se
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently RX status descriptor and RX command descriptor are
represented using the same struct type.
This patch splits this by introducing different types for
rx status and command descriptor.
Doing this make it possible to handle rtl8187se RX descriptors
easier.
This patch do also this by adding specific cases where needed.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Basic rate configuration is a bit different for rtl8187se.
Adding this also fixes the gcc warning introduced in last patch
about unhandled case in switch.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch modifies the TX descriptor struct so it can work also
for rtl8187se.
Some reserved field is now meaningful, and where needed union is
used.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add back rtl8187se chip type to the enum for known chips.
This causes unhandled switch/case warning that will be fixed
in following patch
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adds registers for rtl8187se to the rtl818x common struct
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Sometimes we may end up downloading other commands when host
sleep is configured. This patch makes sure that pending
commands are cancelled and we stop queueing further commands
during host sleep.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Incremented sequence number was not being used for SLEEP confirm
command. This patch fixes the issue.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When next scan command is delayed due to Tx traffic and
meanwhile synchronous command is received followed by a signal,
we cance all pending commands. NULL pointer dereference is seen
in this case while queueing next command in scan delay timer.
This patch adds a check to fix this issue.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The struct cfg80211_connect_params indicate whether the connection
should use management frame protection (mfp). If required set the
MFP_CAPABLE flag in the firmware command. This is supported from
user-space by wpa_supplicant since v2.1.
Reviewed-by: NDaniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Casting a pointer to a pointer of the same type is pointless,
so remove these unnecessary casts.

Around these changes:

o Remove unnecessary parentheses
o Use consistent dereference style (change ptr[0] to *ptr)
o Argument alignment

Done via coccinelle script: (and some typing)

$ cat typecast_2.cocci
@@
type T;
T *foo;
@@

-	(T *)foo
+	foo
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Casting a pointer to a pointer of the same type is pointless,
so remove these unnecessary casts.

Done via coccinelle script:

$ cat typecast_2.cocci
@@
type T;
T *foo;
@@

-	(T *)foo
+	foo
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Casting a pointer to a pointer of the same type is pointless,
so remove these unnecessary casts.

Done via coccinelle script:

$ cat typecast_2.cocci
@@
type T;
T *foo;
@@

-	(T *)foo
+	foo
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using addressof then casting to the original type is pointless,
so remove these unnecessary casts.

Done via coccinelle script:

$ cat typecast.cocci
@@
type T;
T foo;
@@

-	(T *)&foo
+	&foo
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On currently supported HW there are four TX queues (three for normal
packets and one for beacons).

The driver uses just one TX queue, and declare to mac80211 to
support just one queue, but it allocates coherent memory for all
queues.
Furthermore the TX is code is written assumimg four queues exists,
and even if we decide to enable more queues in future, its mapping
rule to mac80211 is fixed.

This means we have memory waste on rtl8180/rtl8185, and we have also
not enough flexibility to add support for boards (rtl8187se) that
will use more queues.

This patch changes things in order to allocate coherent memory only
for the queues effectively used and it make it possible to specify
how to map hardware queues on mac80211 queues, that will be used
by rtl8187se code as soon it will be merged.

Note: even if the beacon queue is currently unused, this should
change, so I kept it.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Hw DMA registers are written in rtl8180_init_hw function.
They are also written again just after calling rtl8180_init_hw.
There is no point in doing this twice.

Remove those redundant register writes from rtl8180_start.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some Broadcom boards have more GPIOs available. For example Linksys
E3200 home router is based on SoC id 0x5357, package 0x0A and uses GPIO
23 to reset internal USB WiFi (gpio23=wombo_reset).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

We should let user space request the peer address also in the pending
connect states, i.e. BT_CONNECT and BT_CONNECT2. There is existing user
space code that tries to do this and will fail without extending the set
of allowed states for the peer address information.

This patch adds the two states to the allowed ones in the L2CAP and
RFCOMM sock_getname functions, thereby preventing ENOTCONN from being
returned.
Reported-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Tested-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The smp variable in smp_conn_security is not used anywhere before the
smp = smp_chan_create() call in the smp_conn_security function so it
makes no sense to assign any other value to it before that.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The smp pointer might not be initialized for jumps to the "done" label
in the smp_conn_security function. Furthermore doing the set_bit after
done might "overwrite" a previous value of the flag in case pairing was
already in progress. This patch moves the call to set_bit before the
label so that it is only done for a newly created smp context (as
returned by smp_chan_create).
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Due to several devices being unable to handle this procedure reliably
(resulting in forced disconnections before pairing completes) it's
better to remove it altogether.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In the case that the just-works model would be triggered we only want to
confirm remotely initiated pairings (i.e. those triggered by a Security
Request or Pairing Request). This patch adds the necessary check to the
tk_request function to fall back to the JUST_WORKS method in the case of
a locally initiated pairing.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

For remotely initiated just-works pairings we want to show the user a
confirmation dialog for the pairing. However, we can only know which
side was the initiator by tracking which side sends the first Security
Request or Pairing Request PDU. This patch adds a new SMP flag to
indicate whether our side was the initiator for the pairing.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In the case that a local pairing confirmation (JUST_CFM) has been
selected as the method we need to use the user confirm request mgmt
event for it with the confirm_hint set to 1 (to indicate confirmation
without any specific passkey value). Without this (if passkey_notify was
used) the pairing would never proceed. This patch adds the necessary
call to mgmt_user_confirm_request in this scenario.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

It is possible that the HCI_LE_Start_Encryption command fails in an
early stage and triggers a command status event with the failure code.
In such a case we need to properly notify the hci_conn object and
cleanly bring the connection down. This patch adds the missing command
status handler for this HCI command.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

If a sudden disconnection happens the l2cap_conn pointer may already
have been cleaned up by the time hci_conn_security gets called,
resulting in the following oops if we don't have a proper NULL check:

BUG: unable to handle kernel NULL pointer dereference at 000000c8
IP: [<c132e2ed>] smp_conn_security+0x26/0x151
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 1 PID: 673 Comm: memcheck-x86-li Not tainted 3.14.0-rc2+ #437
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: f0ef0520 ti: f0d6a000 task.ti: f0d6a000
EIP: 0060:[<c132e2ed>] EFLAGS: 00010246 CPU: 1
EIP is at smp_conn_security+0x26/0x151
EAX: f0ec1770 EBX: f0ec1770 ECX: 00000002 EDX: 00000002
ESI: 00000002 EDI: 00000000 EBP: f0d6bdc0 ESP: f0d6bda0
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 000000c8 CR3: 30f0f000 CR4: 00000690
Stack:
 f4f55000 00000002 f0d6bdcc c1097a2b c1319f40 f0ec1770 00000002 f0d6bdd0
 f0d6bde8 c1312a82 f0d6bdfc c1312a82 c1319f84 00000008 f4d81c20 f0e5fd86
 f0ec1770 f0d6bdfc f0d6be28 c131be3b c131bdc1 f0d25270 c131be3b 00000008
Call Trace:
 [<c1097a2b>] ? __kmalloc+0x118/0x128
 [<c1319f40>] ? mgmt_pending_add+0x49/0x9b
 [<c1312a82>] hci_conn_security+0x4a/0x1dd
 [<c1312a82>] ? hci_conn_security+0x4a/0x1dd
 [<c1319f84>] ? mgmt_pending_add+0x8d/0x9b
 [<c131be3b>] pair_device+0x1e1/0x206
 [<c131bdc1>] ? pair_device+0x167/0x206
 [<c131be3b>] ? pair_device+0x1e1/0x206
 [<c131ed44>] mgmt_control+0x275/0x2d6
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Make sure no timer callback is running before releasing the
datastructure which contains it.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The LE scan type paramter defines if active scanning or passive scanning
is in use. Track the currently set value so it can be used for decision
making from other pieces in the core.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

If vendor specific HCI commands are received from application,
we should send corresponding events to stack.
These events should be consumed in driver, only if they are for
the internal HCI commands generated by driver.

This patch fixes the vendor command 0x3f stuck problem with
above mentioned change. For example,

hcitool cmd 3f 22 fe 06 22 21 20 43 50 00
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

We need to ensure that we do not send events to user space with the
identity address if we have not yet notified user space of the IRK. The
code was previously trying to handle this for the mgmt_pair_device
response (which worked well enough) but this is not the only connection
related event that might be sent to user space before pairing is
successful: another important event is Device Disconnected.

The issue can actually be solved more simply than the solution
previously used for mgmt_pair_device. Since we do have the identity
address tracked as part of the remote IRK struct we can just copy it
over from there to the hci_conn struct once we've for real sent the mgmt
event for the new IRK.
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

In order to support the driver behaviour introduced by:

   commit d0575a5a703978c43e25128421158c78534ba100
   Author: Daniel Kim <dekim@broadcom.com>
   Date:   Wed Mar 12 18:12:14 2014 -0700

       brcmfmac: Enable 40MHz bandwidth in 2GHz band and OBSS scanning

in devices that do not support bwcap firmware command a fallback
is added.
Reviewed-by: NDaniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In the function brcmf_sdiod_request_data() an error message is logged,
but the calling function retries it. This patch will only log an error
message when retry limit is reached. The low-level error is still
logged by a SDIO debug message.
Reviewed-by: NDaniel (Deognyoun) Kim <dekim@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The watchdog thread waits on completion that is set from a timer. As
the completion is count based this could mean that on a busy system
the watchdog is handled multiple times with a very short interval.
This is not the intended behaviour. After handling the watchdog it
should wait for the next timer expiry. This is accomplished by
reinitializing the completion.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch enables 40MHz bandwidth in 2GHz band after checking whether
cfg80211 allows it or not, and enables OBSS scanning operations to
to support 20/40 BSS coexistence.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NDaniel Kim <dekim@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>