summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mac802154: fix transmission power datatypeVarka Bhadram2015-04-092-2/+2
| | | | | | | | | | Netlink attribute for the power is s8. But for the driver level operations we are collection power level value into integer. It has to be change to s8 from int. Signed-off-by: Varka Bhadram <varkab@cdac.in> Acked-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Use proper data structures for Intel vendor eventsMarcel Holtmann2015-04-092-26/+68
| | | | | | | | | | The Intel vendors events indicating firmware loading result and the bootup of the operational firmware are currently hardcoded byte comparisons. So intead of doing that, provide proper data structures and actually use them. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* mac802154: fix typo for deviceVarka Bhadram2015-04-091-1/+1
| | | | | Signed-off-by: Varka Bhadram <varkab@cdac.in> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Read LE remote features during connection establishmentMarcel Holtmann2015-04-092-2/+118
| | | | | | | | | | | | | | | | When establishing a Bluetooth LE connection, read the remote used features mask to determine which features are supported. This was not really needed with Bluetooth 4.0, but since Bluetooth 4.1 and also 4.2 have introduced new optional features, this becomes more important. This works the same as with BR/EDR where the connection enters the BT_CONFIG stage and hci_connect_cfm call is delayed until the remote features have been retrieved. Only after successfully receiving the remote features, the connection enters the BT_CONNECTED state. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add local SSP OOB data to OOB ext data mgmt commandJohan Hedberg2015-04-071-2/+152
| | | | | | | | | | | | | The Read Local Out Of Band Extended Data mgmt command is specified to return the SSP values when given a BR/EDR address type as input parameter. The returned values may include either the 192-bit variants of C and R, or their 256-bit variants, or both, depending on the status of Secure Connections and Secure Connections Only modes. If SSP is not enabled the command will only return the Class of Device value (like it has done so far). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Update SSP OOB data EIR definitionsJohan Hedberg2015-04-071-2/+4
| | | | | | | | | Since Bluetooth 4.1 there are two additional values for SSP OOB data, namely C-256 and R-256. This patch updates the EIR definitions to take into account both the 192 and 256 bit variants of C and R. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: hci_uart: Use generic Intel support for address settingMarcel Holtmann2015-04-074-22/+4
| | | | | | | | | The Bluetooth address setting for Intel devices is provided by a generic module now. Start using that module instead of relying it being included in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Move Intel command structs into its own headerMarcel Holtmann2015-04-072-33/+33
| | | | | | | | Since the Intel Bluetooth support has its own header, it makes sense to move all command structs into it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Use generic Intel support for address supportMarcel Holtmann2015-04-072-70/+10
| | | | | | | | | The Bluetooth address handling for Intel devices is provided by a generic module now. Start using that module instead of relying it being included in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btintel: Introduce generic Intel Bluetooth supportMarcel Holtmann2015-04-074-0/+146
| | | | | | | | | | | The majority of Intel Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Intel specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Provide generic H:4 receive frameworkMarcel Holtmann2015-04-074-60/+110
| | | | | | | | | | | | Future H:4 based UART drivers require custom packet types and custom receive functions. To support this, extended the h4_recv_buf function with a packet definition table. For the default H:4 packets types of ACL data, SCO data and events, provide helpers to reduce the amount of code duplication. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Add firmware table for UART based devicesMarcel Holtmann2015-04-071-15/+41
| | | | | | | | The Broadcom UART based devices seem to use a little bit different firmare naming prefix. So add a separate table for these devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Add protocol support for Broadcom UART devicesMarcel Holtmann2015-04-074-0/+127
| | | | | | | | | | This adds the protocol support for Broadcom based UART devices to enable firmware and patchram download procedure. It is a pretty straight forward H:4 driver with the exception of actually having its own setup and address configuration callbacks. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Move setup callback into different locationMarcel Holtmann2015-04-071-1/+1
| | | | | | | | The setup callback got wrongly inserted between the enqueue and dequeue callbacks. Move it to a better location. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Update version number of the moduleMarcel Holtmann2015-04-071-1/+1
| | | | | | | | | The version number is cosmetic, but pretty handy for debugging purposes and since the Broadcom protocol support is now optional, just increase it to indicate the difference. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Move Broadcom quirk setting into support moduleMarcel Holtmann2015-04-072-4/+5
| | | | | | | | The quirks for Broadcom devices can be set from the setup function and to keep the code simple, just move them into Broadcom support module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Add option for Broadcom protocol supportMarcel Holtmann2015-04-072-208/+15
| | | | | | | | | | | | With the generic Broadcom Bluetooth support module, it is possible to turn support for firmware and patchram download into an optional feature. To keep backwards compatibility with previous kernel configurations, the new option defaults to enabled. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Add support for Broadcom controller setupMarcel Holtmann2015-04-073-0/+272
| | | | | | | | To unify the controller setup of Broadcom devices between USB and UART transport, add the patchram download support into the Broadcom module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Use generic functionality from Broadcom moduleMarcel Holtmann2015-04-074-22/+4
| | | | | | | | | The new Broadcom Bluetooth support module provides generic functionality for changing and checking the Bluetooth device address. Use these new features instead of keeping a duplicate in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btusb: Use generic functionality by Broadcom moduleMarcel Holtmann2015-04-072-58/+5
| | | | | | | | | The new Broadcom Bluetooth support module provides generic functionality for changing and checking the Bluetooth device address. Use these new features instead of keeping a duplicate in the driver. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: btbcm: Introduce generic Broadcom Bluetooth supportMarcel Holtmann2015-04-074-0/+144
| | | | | | | | | | | The majority of Broadcom Bluetooth vendor commands are shared between USB and UART transports. This creates a separate module that eventually will hold all Broadcom specific commands, but for now just start with the commands to change the Bluetooth public address and check for the default address. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Update version number driverMarcel Holtmann2015-04-073-5/+1
| | | | | | | | | | | This version number is more cosmetic and for debugging purposes, but since there has been a few changes lately, increase it now. Two left-over and not used version constants that were never exposed anywhere are removed since they have no actual value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Remove the manual protocol init messageMarcel Holtmann2015-04-076-40/+7
| | | | | | | | | The init function for each HCI UART protocol prints the same on success and failure. This information is so generic, remove it and let the main HCI UART handling print it instead. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Add name information to hci_uart_proto structMarcel Holtmann2015-04-076-7/+13
| | | | | | | | This adds an extra name field to the hci_uart_proto struct that provides a simple way of adding a string identifier to the protocol. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Make struct hci_uart_proto always constMarcel Holtmann2015-04-077-13/+13
| | | | | | | | The usage of struct hci_uart_proto should always be const. Change the function headers and individual protocol drivers. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Remove hci_recv_stream_fragment functionMarcel Holtmann2015-04-072-150/+1
| | | | | | | | | | | | | | | | The hci_recv_stream_fragment function should have never been introduced in the first place. The Bluetooth core does not need to know anything about the HCI transport protocol. With all transport protocol specific detailed moved back into the drivers where they belong (mainly generic USB and UART drivers), this function can now be removed. This reduces the size of hci_dev structure and also removes an exported symbol from the Bluetooth core module. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Use h4_recv_buf helper for Atheros AR300xMarcel Holtmann2015-04-072-5/+10
| | | | | | | | | | Instead of using hci_recv_stream_fragment, use the local available h4_recv_buf helper function. To ensure that the function is available select BT_HCIUART_H4. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Use h4_recv_buf helper for H:4 protocolMarcel Holtmann2015-04-071-5/+9
| | | | | | | | Instead of using hci_recv_stream_fragment, use the local available h4_recv_buf helper function. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Introduce h4_recv_buf helper functionMarcel Holtmann2015-04-072-0/+101
| | | | | | | | | The h4_recv_buf helper function can be used for receiving H:4 packets out of a TTY stream. It is self-contained and allows for reuse by all HCI UART protocols. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Use const data pointer for received dataMarcel Holtmann2015-04-077-10/+10
| | | | | | | | | | The TTY layer provides its data pointers as const, but the HCI UART callbacks expect them as general data pointers. This is of course wrong and instead of casting them, just fix the individual drivers to actually take a const data pointer. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Make data pointer of hci_recv_stream_fragment constMarcel Holtmann2015-04-072-4/+4
| | | | | | | | | The data pointer provided to hci_recv_stream_fragment function should have been marked const. The function has no business in modifying the original data. So fix this now. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Remove unused h4->rx_state and h4->rx_count fieldMarcel Holtmann2015-04-071-2/+0
| | | | | | | | The fields h4->rx_state and h4->rx_count are not used at all and with that they can be just removed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Remove unused h4->rx_skb fieldMarcel Holtmann2015-04-071-3/+0
| | | | | | | | | The h4->rx_skb is not used anymore and with that just remove it. Seems this was a leftover and even the kfree_skb call freeing it is rather pointless since it got never allocated. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Fix indentation issues for multi-line functionsMarcel Holtmann2015-04-071-6/+7
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Remove unneeded cast of tty->disc_dataMarcel Holtmann2015-04-071-4/+4
| | | | | | | | Casting the tty->disc_data to (void *) is not needed at all. So just remove this cast and assign the object without a cast. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Add support Broadcom address configurationMarcel Holtmann2015-04-075-1/+69
| | | | | | | | When using vendor detection, this adds support for the Broadcom specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Add support Intel address configurationMarcel Holtmann2015-04-075-1/+69
| | | | | | | | When using vendor detection, this adds support for the Intel specific address configuration command. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: hci_uart: Add support for vendor detection flagMarcel Holtmann2015-04-072-1/+29
| | | | | | | | | | | | | | | This adds a new HCI_UART_VND_DETECT flag to allow automatic vendor detection. This allows to enable known vendor commands (for example for setting the public device address) when using a standard H:4 UART protocol or when running in virtual machines. When this new flag is configured and no vendor specific setup routine is provided, then the local version information are read and the provided manufacturer information can be evaluated to configure extra vendor callbacks. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Merge branch 'for-upstream' of ↵David S. Miller2015-04-0722-338/+570
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2015-04-04 Here's what's probably the last bluetooth-next pull request for 4.1: - Fixes for LE advertising data & advertising parameters - Fix for race condition with HCI_RESET flag - New BNEPGETSUPPFEAT ioctl, needed for certification - New HCI request callback type to get the resulting skb - Cleanups to use BIT() macro wherever possible - Consolidate Broadcom device entries in the btusb HCI driver - Check for valid flags in CMTP, HIDP & BNEP - Disallow local privacy & OOB data combo to prevent a potential race - Expose SMP & ECDH selftest results through debugfs - Expose current Device ID info through debugfs Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * Bluetooth: Fix location of TX power field in LE advertising dataMarcel Holtmann2015-04-041-6/+8
| | | | | | | | | | | | | | | | | | The TX power field in the LE advertising data should be placed last since it needs to be possible to enable kernel controlled TX power, but still allow for userspace provided flags field. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: hidp: Use BIT(x) instead of (1 << x)Marcel Holtmann2015-04-041-2/+2
| | | | | | | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: cmtp: Use BIT(x) instead of (1 << x)Marcel Holtmann2015-04-042-3/+3
| | | | | | | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: bnep: Handle BNEP connection setup requestGrzegorz Kolodziejczyk2015-04-033-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | With this patch kernel will be able to handle setup request. This is needed if we would like to handle control mesages with extension headers. User space will be only resposible for reading setup data and checking if scenario is conformance to specification (dst and src device bnep role). In case of new user space, setup data must be leaved(peek msg) on queue. New bnep session will be responsible for handling this data. Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: bnep: Add support to extended headers of control framesGrzegorz Kolodziejczyk2015-04-031-10/+36
| | | | | | | | | | | | | | | | | | | | | | Handling extended headers of control frames is required BNEP functionality. This patch refractor bnep rx frame handling function. Extended header for control frames shouldn't be omitted as it was previously done. Every control frame should be checked if it contains extended header and then every extension should be parsed separately. Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: bnep: Add support for get bnep features via ioctlGrzegorz Kolodziejczyk2015-04-033-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed if user space wants to know supported bnep features by kernel, e.g. if kernel supports sending response to bnep setup control message. By now there is no possibility to know supported features by kernel in case of bnep. Ioctls allows only to add connection, delete connection, get connection list, get connection info. Adding connection if it's possible (establishing network device connection) is equivalent to starting bnep session. Bnep session handles data queue of transmit, receive messages over bnep channel. It means that if we add connection the received/transmitted data will be parsed immediately. In case of get bnep features we want to know before session start, if we should leave setup data on socket queue and let kernel to handle with it, or in case of no setup handling support, if we should pull this message and handle setup response within user space. Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: bnep: Return err value while sending cmd is not understoodGrzegorz Kolodziejczyk2015-04-031-1/+1
| | | | | | | | | | | | | | | | Send command not understood response should be verified if it was successfully sent, like all send responses. Signed-off-by: Grzegorz Kolodziejczyk <grzegorz.kolodziejczyk@tieto.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Disallow LE local out-of-band data when LE privacy is usedMarcel Holtmann2015-04-021-6/+19
| | | | | | | | | | | | | | | | | | | | When the LE pivacy feature is used, then pairing has to happen based on resolvable random addresses (RPA), but currently there is no clean way to retrieve the correct RPA. So instead of returning an outdated RPA, just disallow this command when LE privacy is in use. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Convert local OOB data reading to use HCI requestJohan Hedberg2015-04-023-54/+65
| | | | | | | | | | | | | | | | | | | | | | | | Now that there's a HCI request API available where the callback receives the resulting skb, we can convert the local OOB data reading to use this new API. This patch does the necessary update in mgmt.c (which also requires moving the callback higher up since it's now a static function) and removes the custom calls from hci_event.c that are no-longer necessary. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Move hci_get_cmd_complete() to hci_event.cJohan Hedberg2015-04-022-51/+58
| | | | | | | | | | | | | | | | | | | | | | | | To make the hci_req_run_skb() API consistent with hci_cmd_sync_ev() the callback should receive the cmd_complete parameters in the 'normal' case and the full HCI event if a special event was expected. This patch moves the hci_get_cmd_complete() function from hci_core.c to hci_event.c where it's used to strip the skb from the needed headers before passing it on to the callback. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Remove unused hci_req_pending() functionJohan Hedberg2015-04-022-7/+0
| | | | | | | | | | | | | | | | The hci_req_pending() function has no users anymore, so simply remove it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
OpenPOWER on IntegriCloud