We can safely remove the link type check from hci_disconn_complete_
evt() since this check in not required for mgmt_disconnect_failed()
and mgmt_device_disconnected() does it internally.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds an extra check in mgmt_device_disconnected() so we only
send the "Device Disconnected" event if it is ACL_LINK or LE_LINK link
type.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Check the address and address type in mgmt_disconnect_failed() otherwise
we may wrongly fail the MGMT_OP_DISCONNECT command.
Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The device tree property can define the cal-data in proper order.
There is no need to swap the bytes in driver.
Also remove the redundant cal-data memory copy after removing the
byte swapping.

Cc: Mike Frysinger <vapier@chromium.org>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NHyuckjoo Lee <hyuckjoo.lee@samsung.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some ARM versions of Chromebook need to download a new calibration
data from host driver to firmware. They do have EEPROM but still
need a piece of new calibration data in test mode.

The cal-data is platform dependent. It's simpler and more feasible
to use device tree based cal-data instead of configuration file
based cal-data.

This patch remove configuration file based cal-data downloading
and replace it using cal-data from device tree.

When CONFIG_OF is not selected, or the specific property is not
present in the device tree, the calibration downloading will not
happen.

Cc: Mike Frysinger <vapier@chromium.org>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NHyuckjoo Lee <hyuckjoo.lee@samsung.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Replace ogf/ocf and its packing with 16-bit opcodes.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The list of supported commands of a controller can not change during
its lifetime. So store the list just once during the setup procedure
and not every time the HCI command is executed.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The complete list of local features are available through debugfs and
so there is no need to add a debug print here.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

The default own address type is currently set at every power on of
a controller. This overwrites the value set via debugfs. To avoid
this issue, set the default own address type only during controller
setup.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

There is an old Panasonic module with a Zeevo chip in there that is
not really operating according to Bluetooth core specification when
it comes to setting the IAC LAP for limited discoverable mode.

For reference, this is the vendor information about this module:

  < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
  > HCI Event: Command Complete (0x0e) plen 12
        Read Local Version Information (0x04|0x0001) ncmd 1
          Status: Success (0x00)
          HCI version: Bluetooth 1.2 (0x02) - Revision 196 (0x00c4)
          LMP version: Bluetooth 1.2 (0x02) - Subversion 61 (0x003d)
          Manufacturer: Zeevo, Inc. (18)

The module reports only the support for one IAC at a time. And that
is totally acceptable according to the Bluetooth core specification
since the minimum supported IAC is only one.

  < HCI Command: Read Number of Supported IAC (0x03|0x0038) plen 0
  > HCI Event: Command Complete (0x0e) plen 5
        Read Number of Supported IAC (0x03|0x0038) ncmd 1
          Status: Success (0x00)
          Number of IAC: 1

The problem arises when trying to program two IAC into the module
on a controller that only supports one.

  < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 7
          Number of IAC: 2
          Access code: 0x9e8b00 (Limited Inquiry)
          Access code: 0x9e8b33 (General Inquiry)
  > HCI Event: Command Status (0x0f) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Unknown HCI Command (0x01)

While this looks strange, but according to the Bluetooth core
specification it is a legal operation. The controller has to
ignore the other values and only program as many as it supports.

  This command shall clear any existing IACs and stores Num_Current_IAC
  and the IAC_LAPs in to the controller. If Num_Current_IAC is greater
  than Num_Support_IAC then only the first Num_Support_IAC shall be
  stored in the controller, and a Command Complete event with error
  code Success (0x00) shall be generated.

This specific controller has a bug here and just returns an error. So
in case the number of supported IAC is less than two and the limited
discoverable mode is requested, now only the LIAC is written to
the controller.

  < HCI Command: Write Current IAC LAP (0x03|0x003a) plen 4
          Number of IAC: 1
          Access code: 0x9e8b00 (Limited Inquiry)
  > HCI Event: Command Complete (0x0e) plen 4
        Write Current IAC LAP (0x03|0x003a) ncmd 1
          Status: Success (0x00)

All other controllers that only support one IAC seem to handle this
perfectly fine, but this fix will only write the LIAC for these
controllers as well.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>

Adding the debugfs file <debugfs_mnt>/brcmfmac/<devid>/chipinfo
which contains the chip number and revision.
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>

The dhd.h file contained a number of definitions that are
related to events received from the firmware. Those are
processed and dispatched in the driver by fweh. Hence the
definitions are moved to its include file.
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>

Removing WLC_PHY_TYPE and some BRCMF_E_.* definitions as these
are not used in the driver sources.
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>

The BCDC protocol layer is using a mix of naming of CDC, BDC and
BCDC. Use the name BCDC consistenly over all functions, defines
and variables. This patch does not change code functionality.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the command codes to the firmware interface module as
that makes a bit more sense.
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>

The firmware control interface is provided by fwil source file, but
a number of structures used to communicate with the firmware still
resided in dhd.h. The patch moves them to fwil_types.h.
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>

In bcmsdh.c the functions brcmf_sdio_probe() and brcmf_sdio_remove()
were exported, but that is not needed. The functions are linked into
the driver module, which is the only one needing to call these.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NDaniel (Deognyoun) Kim <dekim@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Knowing the firmware version is pretty useful information when
looking at issues. It is retrieved during initialization so
store it in driver data structure to fill the ethtool driver
info when requested.
Reviewed-by: NHante Meuleman <meuleman@brodcom.com>
Reviewed-by: NFranky Lin <frankyl@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>

BCDC is the default protocol layer and being called directly. This
patch installs the functions for this layer dynamically. This allows
new protocols to be added and selected dynamically depending on the
hw capabilties. As currently only BCDC is supported this is always
the installed protocol.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The ioctl() entry points were empty except for handling SIOC_ETHTOOL
but that has been obsoleted in favor of struct ethtool_ops. Cleaning
up removing the ioctl() handlers.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NFranky Lin <frankyl@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 SDIO part of the brcmfmac driver uses a static define BRCMF_SDALIGN
to align buffers used for SDIO transfers. This patch replaces it by
using alignment derived from the platform specific data.
Reviewed-by: NFranky Lin <frankyl@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>

The alignment values were being determined for each transmit
and receive depending on platform data. Instead determine
these once during the probe.
Reviewed-by: NFranky Lin <frankyl@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>

dhd_proto.h was cleaned up and prototypes were moved to dhd.h.
dhd_proto.h was removed. This is a step in cleaning and
restucturing protocol layer.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

dhd_cdc is renamed to bcdc. This is a step in cleaning and
restructuring protocol layer. This is done so new protocols can
be added in the future. This step only renames the source files.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
[arend@broadcom.com: use 'git mv' to do the rename]
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New WiFi full dongle supports receiving chained packets in one command
through the SDIO bus. This patch adds the support on the host side to
send chained packets.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add firmware/nvram file name for bcm4339 so fmac can actually be functional with
the chip.
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When CONFIG_BRCMDBG is not set we get the following build issue:
  CC [M]  drivers/net/wireless/brcm80211/brcmfmac/fwsignal.o
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:
    In function ‘brcmf_fws_hdrpush’:
	drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:852:18:
	error: ‘BRCMF_FWS_TYPE_SEQ_LEN’ undeclared

The define BRCMF_FWS_TYPE_SEQ_LEN was introduced by:

    commit 6918f38e4ed4e0493a90a4331e0033bdfc806e00
    Author: Hante Meuleman <meuleman@broadcom.com>
    Date:   Wed Oct 23 14:58:51 2013 +0200

        brcmfmac: Update fwsignal to fix out of order tx.

Unfortunately, it was put in conditional part of the source
file under #ifdef DEBUG.
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>

The commit "eb9c174 brcmfmac: determine host controller related
variables during probe" was not implemented correctly as the
information is already needed in brcmf_sdbrcm_probe(). This patch
moves it to brcmf_sdioh_attach() instead.
Reviewed-by: NFranky Lin <frankyl@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>

The SDPCM header can be traced, but it used a fixed header size. With
txglom feature the SDPCM header will have additional 8 bytes of hardware
extension header so SDIO core can properly handle the txglom packet.
Reviewed-by: NFranky Lin <frankyl@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>

The brcmsmac relies BCMA functionality to access the device. This
patch selects CONFIG_BCMA when CONFIG_BCMA_POSSIBLE is set. This
way the user does not need to be select BCMA to make the brcmsmac
driver show up in his menuconfig.
Reported-by: NDan Carpenter <dan.carpenter@oracle.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>

The SleepCSR register is accessed to wakeup the device from the
host side. Depending on the state of the device this may take
multiple attempts. The failed attempt are not real failures so
reduce the log level specifically for this register. The calling
function will scream when the multiple attempts all failed.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

remove empty brcmf_proto_stop from protocol layer
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NFranky Lin <frankyl@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Moving the call to netif_start_queue() after brcmf_cfg80211_up() is
completed successful. If not return -EIO instead of -1 as that results
in 'Operation not permitted' which can put user on wrong track.
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The bus-specific interface allowed a list of dongle commands to be
provided to the common driver part. However, upcoming functionality
requires a more dynamic behaviour. Hence the list is replaced
by a new callback function so the bus-specific driver part can
implement this behaviour.
Reviewed-by: NFranky Lin <frankyl@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>

The common driver needs the packet overhead for the bus in order
to reserve headroom for sk_buffs. For the SDIO driver this depends
on firmware features so it is not possible to provide it in the
brcmf_attach() call.
Reviewed-by: NFranky Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When using fwsignal it is possible that tx packets get delivered out
of order. This patch fixes that by reordering suppressed packets and
tracking generation bit and sequence number per packet.
Reviewed-by: NArend Van Spriel <arend@broadcom.com>
Reviewed-by: NFranky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is missing for AR9300, AR9580 and AR9340.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Baseband updates
* Remove ar9340Common_rx_gain_table_1p0 since it is a duplicate.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>