The Marvell Bluetooth SDIO driver has a really complicated concept on how
firmware names are assigned to specific device ids. Fix that by doing a
proper structure and assign it to the module device table.

And while at it fix various coding style weirdness that is still present
in this driver.
Signed-off-by: Marcel Holtman <marcel@holtmann.org>

The Marvell core Bluetooth driver has various weird casting and unneeded
braces in its code that makes it hard to read. Remove all of these to
make the code a little bit simpler.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The Marvell Bluetooth driver has debugfs support and they are casting
like there is no tomorrow. Remove all of them and magically the code
becomes more readable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Both header files of the Marvell Bluetooth driver are private anyway and
if the driver happens to include them twice or they create a circular
dependency then the driver needs fixing. So just remove both pointless
ifdefs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The Makefile entry for the Marvell driver is broken when it comes to
handling the optional DEBUG_FS correctly. That must have been the reason
why they were using select in Kconfig in the first place. Fix this and
make it really optional.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The Marvell driver selects DEBUG_FS and FW_LOADER for its core driver
and that is pointless. Don't select DEBUG_FS since it is either enabled
or not and it is not for the driver to enable it. Also FW_LOADER is
only used within the SDIO driver and so just have that one select the
FW_LOADER option.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

add btmrvl.txt to Documentation/

This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

/debug/btmrvl/config/
/debug/btmrvl/status/

See Documentation/btmrvl.txt for details.

This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This driver supports Marvell Bluetooth enabled devices with SDIO
interface. Currently only SD8688 chip is supported.

The helper/firmware images of SD8688 can be downloaded from this tree:
git://git.infradead.org/users/dwmw2/linux-firmware.git

This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This driver provides basic definitions and library functions to
support Marvell Bluetooth enabled devices, such as 88W8688 WLAN/BT
combo chip.

This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The core exports the hci_conn_hold_device() and hci_conn_put_device()
functions for device reference of connections. Use this to ensure that
the uevents from the parent are send after the child ones.

Based on a report by Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The device model itself has no real usable reference counting at the
moment and this causes problems if parents are deleted before their
children. The device model itself handles the memory details of this
correctly, but the uevent order is not consistent. This causes various
problems for systems like HAL or even X.

So until device_put() does a proper cleanup, the device for Bluetooth
connection will be protected with an extra reference counting to ensure
the correct order of uevents when connections are terminated.

This is not an automatic feature. Higher Bluetooth layers like HIDP or
BNEP should grab this new reference to ensure that their uevents are
send before the ones from the parent device.

Based on a report by Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Currently the HID subsystem will create HIDRAW devices for the transport
driver, but it will not disconnect them. Until the HID subsytem gets
fixed, ensure that HIDRAW and HIDDEV devices are disconnected when the
Bluetooth HID device gets removed.

Based on a patch from Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch increases the receive buffer size to HCI_MAX_FRAME_SIZE
which improves the RX throughput considerably.

Tested against BRM/Atheros/CSR USB Dongles with PAN profile using
iperf and chariot. This gave significant (around 40%) increase
in performance (increased from 0.8 to 1.5 Mb/s in Sheld room)
Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

There is a test case in PTS tool; PTS will send the VIRTUAL_CABLE_UNPLUG
command to IUT. Then IUT should disconnect the channel and kill the HID
session when it receives the command. The VIRTUAL_CABLE_UNPLUG command
is parsed by HID transport, but it is not scheduled to do so. Add a
call to hidp_schedule() to kill the session.
Signed-off-by: Jothikumar Mothilal <jothikumar.mothilal@atheros.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The SCO sockets for Bluetooth audio setup and streaming are missing the
shutdown implementation. This hasn't been a problem so far, but with a
more deeper integration with PulseAudio it is important to shutdown SCO
sockets properly.

Also the Headset profile 1.2 has more detailed qualification tests that
require that SCO and RFCOMM channels are terminated in the right order. A
proper shutdown function is necessary for this.

Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The current mwl8k_priv->fw_lock spinlock doesn't actually protect
against multiple commands being submitted at once, as it is not kept
held over the entire firmware command submission.  And since waiting
for command completion sleeps, we can't use a spinlock anyway.

To fix mwl8k firmware command serialisation properly, we have the
following requirements:
- Some commands require that the packet transmit path is idle when
  the command is issued.  (For simplicity, we'll just quiesce the
  transmit path for every command.)
- There are certain sequences of commands that need to be issued to
  the hardware sequentially, with no other intervening commands.

This leads to an implementation of a "firmware lock" as a mutex that
can be taken recursively, and which is taken by both the low-level
command submission function (mwl8k_post_cmd) as well as any users of
that function that require issuing of an atomic sequence of commands,
and quiesces the transmit path whenever it's taken.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Delete most of the mwl8k_work_struct fields and options, since most
of them are unused or never changed from their defaults:
- We always use priv->config_wq, so delete the wqueue argument from
  mwl8k_queue_work().
- MWL8K_WQ_SPIN and MWL8K_WQ_POST_REQUEST are never used, as all
  callers sleep for request completion, so sleep unconditionally.
- MWL8K_WQ_FREE_WORKSTRUCT is never used.
- MWL8K_WQ_TX_WAIT_EMPTY is always set, so assume it unconditionally.
- timeout_ms/txwait_attempts/tx_timeout_ms are never changed from
  their defaults, so just hardcode these in the workqueue worker.
- step is never used.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Various mwl8k_txq_xmit changes:
- Extract the QoS field before adding the DMA header.
- Only write to tx->status once, and only after all the other
  descriptor fields have been set.
- Do all tx state manipulation under the tx spinlock.
- Remove the priv->inconfig check, as all transmit queues will
  be frozen during config cycles, so we won't ever be asked to
  transmit if a config cycle is running.
- Remove some more dead code.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Use MWL8K_TX_QUEUES instead of a hardcoded "4" in a couple of places.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Since firmware load commands don't generate 'command done' interrupts
like normal commands do, polling for command done interrupts just
unnecessarily slows down the firmware load process.  Removing this bit
of code speeds up loading a typical firmware image from 840 msec to
180 msec.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Adding and removing the DMA header that the mwl8k hardware requires
on tx and provides on rx can never fail, since we are guaranteed to
have enough headroom on the tx path to expand the packet, and we only
ever shrink the packet on the rx path.  (And on both paths we are
guaranteed to be the only user of the skb we are handling.)

This allows removing all of the skb clone handling in the tx and tx
reclaim paths, and eliminates error checks in both the tx and rx
paths, simplifying the code a bit more.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

There is no need to check for NL80211_IFTYPE_MONITOR in
->add_interface(), as this function is never called for monitor
interfaces.  Also, there is no need to advertise this bit in our
wiphy's ->interface_modes.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mwl8k_configure_filter() passes pointers to total_flags and the
multicast address list to a workqueue function, while there is no
guarantee that those pointers will still be valid by the time the
workqueue function runs.

Solve this by passing total_flags by value, and by passing an
already built multicast address setup command packet to the workqueue
function so that we don't have to look at the multicast address list
itself outside of mwl8k_configure_filter().

Also, since ->configure_filter() can sleep now, wait synchronously
for the worker to finish.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>