- 04 Dec, 2013 18 commits
-
-
Johan Hedberg authored
This function was always just making a single get_random_bytes() call and always returning the value 0. It's simpler to just call get_random_bytes() directly where needed. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
Tedd Ho-Jeong An authored
This patch enables autosuspend for Intel Bluetooth device. After btusb is loaded for Intel Bluetooth device, the power/control attribute contains "on" value by default which disables the autosuspend. Based on the USB PM document(Documentation/usb/power-management.txt), kernel disabled the autosuspend for all devices other than hub by default. "The USB specification states that all USB devices must support power management. Nevertheless, the sad fact is that many devices do not support it very well. You can suspend them all right, but when you try to resume them they disconnect themselves from the USB bus or they stop working entirely. This seems to be especially prevalent among printers and scanners, but plenty of other types of device have the same deficiency. For this reason, by default the kernel disables autosuspend (the power/control attribute is initialized to "on") for all devices other than hubs. Hubs, at least, appear to be reasonably well-behaved in this regard." This document also described how the driver can enables the autosuspend by using an USB api. "Drivers can enable autosuspend for their devices by calling usb_enable_autosuspend(struct usb_device *udev); in their probe() routine, if they know that the device is capable of suspending and resuming correctly. This is exactly equivalent to writing "auto" to the device's power/control attribute." For Intel Bluetooth device, the autosuspend needs to be enabled so the device can transit to LPM(Low Power Mode) and ULPM(Ultra LPM) states after receiving suspend message from the host. Signed-off-by:
Tedd Ho-Jeong An <tedd.an@intel.com> Signed-off-by:
-
Tedd Ho-Jeong An authored
This patch adds support for new Intel Bluetooth device. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=0a2a Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
-
Andre Guedes authored
hci_disconn_complete_evt() logic is more complicated than what it should be, making it hard to follow and add new features. So this patch does some code refactoring by handling the error cases in the beginning of the function and by moving the main flow into the first level of function scope. No change is done in the event handling logic itself. Besides organizing this messy code, this patch makes easier to add code for handling LE auto connection (which will be added in a further patch). Signed-off-by:
Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
-
Andre Guedes authored
According to b644ba33 (patch that introduced HCI_CONN_MGMT_CONNECTED flag), the HCI_CONN_MGMT_CONNECTED flag tracks when mgmt has been notified about the connection. That being said, there is no point in calling mgmt_disconnect_failed() conditionally based on this flag. mgmt_disconnect_failed() removes pending MGMT_OP_DISCONNECT commands, it doesn't matter if that connection was notified or not. Moreover, if the Disconnection Complete event has status then we have nothing else to do but call mgmt_disconnect_failed() and return. Signed-off-by:
-
Sujith Manoharan authored
T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 9 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e05f Rev= 0.02 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Reported-by:
Joshua Richenhagen <richenhagen@gmail.com> Signed-off-by:
Sujith Manoharan <sujith@msujith.org> Signed-off-by:
-
Sujith Manoharan authored
T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=300b Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Reported-by:
Face <falazemi@gmail.com> Signed-off-by:
-
Johan Hedberg authored
The send parameter has only been used for determining whether to send a Pairing Failed PDU or not. However, the function can equally well use the already existing reason parameter to make this choice and send the PDU whenever a non-zero value was passed. Signed-off-by:
-
Andre Guedes authored
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:
-
Andre Guedes authored
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:
-
Andre Guedes authored
Check the address and address type in mgmt_disconnect_failed() otherwise we may wrongly fail the MGMT_OP_DISCONNECT command. Signed-off-by:
-
Bing Zhao authored
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:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
Hyuckjoo Lee <hyuckjoo.lee@samsung.com> Signed-off-by:
-
Bing Zhao authored
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:
-
Bing Zhao authored
Replace ogf/ocf and its packing with 16-bit opcodes. Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
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:
-
Marcel Holtmann authored
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:
-
- 02 Dec, 2013 22 commits
-
-
-
Arend van Spriel authored
Adding the debugfs file <debugfs_mnt>/brcmfmac/<devid>/chipinfo which contains the chip number and revision. Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Arend van Spriel authored
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:
-
Arend van Spriel authored
Removing WLC_PHY_TYPE and some BRCMF_E_.* definitions as these are not used in the driver sources. Reviewed-by:
-
Hante Meuleman authored
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:
-
Arend van Spriel authored
Move the command codes to the firmware interface module as that makes a bit more sense. Reviewed-by:
-
Arend van Spriel authored
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:
-
Arend van Spriel authored
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:
Franky Lin <frankyl@broadcom.com> Reviewed-by:
Daniel (Deognyoun) Kim <dekim@broadcom.com> Signed-off-by:
-
Arend van Spriel authored
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:
Hante Meuleman <meuleman@brodcom.com> Reviewed-by:
-
Hante Meuleman authored
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:
-
Arend van Spriel authored
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:
-
Arend van Spriel authored
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:
-
Arend van Spriel authored
The alignment values were being determined for each transmit and receive depending on platform data. Instead determine these once during the probe. Reviewed-by:
-
Hante Meuleman authored
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:
-
Hante Meuleman authored
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:
-
Franky Lin authored
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:
-
Franky Lin authored
Add firmware/nvram file name for bcm4339 so fmac can actually be functional with the chip. Reviewed-by:
-
Arend van Spriel authored
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: -
Arend van Spriel authored
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:
-
Arend van Spriel authored
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:
-
Arend van Spriel authored
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:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Arend van Spriel authored
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:
-
