summaryrefslogtreecommitdiffstats
path: root/net/bluetooth (follow)
Commit message (Collapse)AuthorAgeFilesLines
* net: Pass kern from net_proto_family.create to sk_allocEric W. Biederman2015-05-117-17/+17
| | | | | | | | | In preparation for changing how struct net is refcounted on kernel sockets pass the knowledge that we are creating a kernel socket from sock_create_kern through to sk_alloc. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Add a struct net parameter to sock_create_kernEric W. Biederman2015-05-111-1/+1
| | | | | | | | This is long overdue, and is part of cleaning up how we allocate kernel sockets that don't reference count struct net. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Bluetooth: hidp: Fix regression with older userspace and flags validationMarcel Holtmann2015-04-181-1/+2
| | | | | | | | | | | | | | While it is not used by newer userspace anymore, the older userspace was utilizing HIDP_VIRTUAL_CABLE_UNPLUG and HIDP_BOOT_PROTOCOL_MODE flags when adding a new HIDP connection. The flags validation is important, but we can not break older userspace and with that allow providing these flags even if newer userspace does not use them anymore. Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Bluetooth: Read LE remote features during connection establishmentMarcel Holtmann2015-04-091-2/+105
| | | | | | | | | | | | | | | | 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: Remove hci_recv_stream_fragment functionMarcel Holtmann2015-04-071-147/+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: Make data pointer of hci_recv_stream_fragment constMarcel Holtmann2015-04-071-3/+3
| | | | | | | | | 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: 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-032-0/+8
| | | | | | | | | | | | | | | | | | | 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-022-51/+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-021-5/+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>
* Bluetooth: Remove unneeded recv_event variableJohan Hedberg2015-04-022-15/+0
| | | | | | | | | Now that the synchronous HCI requests use the new API and a new private variable the recv_evt member of hci_dev is no-longer needed. This patch removes it. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Convert hci_req_sync family of function to new request APIJohan Hedberg2015-04-021-14/+14
| | | | | | | | | | | Now that there's an API in place that allows passing the resulting skb to the request callback we can conveniently convert the hci_req_sync and related functions to use it. Since we still need to get the skb from the async callback into the sleeping _sync() function the patch adds another req_skb variable to hci_dev where the sync request state is tracked. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add second hci_request callback option for full skbJohan Hedberg2015-04-024-44/+81
| | | | | | | | | | | | | | | | | | | | This patch adds a second possible callback for HCI requests where the callback will receive the full skb of the last successfully completed HCI command. This API is useful for cases where we want to use a request to read some data and the existing hci_event.c handlers do not store it e.g. in the hci_dev struct. The reason the patch is a bit bigger than just adding the new API is because the hci_req_cmd_complete() functions required some refactoring to enable it: now hci_req_cmd_complete() is simply used to request the callback pointers if any, and the actual calling of them happens from a single place at the end of hci_event_packet(). The reason for this is that we need to pass the original skb (without any skb_pull, etc modifications done to it) and it's simplest to keep track of it within the hci_event_packet() function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add clarifying comment to command status handlingJohan Hedberg2015-04-021-0/+6
| | | | | | | | | | When dealing with HCI command status events, the reasoning for trying to mark a request as complete if no specific event is being waited for and status was success is not self-evident. This patch adds a clarifying comment above the if-statement. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Export SMP selftest result in debugfsMarcel Holtmann2015-04-021-9/+34
| | | | | | | | | When SMP selftest is enabled, then besides printing the result into the kernel message buffer, also create a debugfs file that allows retrieving the same information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Export ECDH selftest result in debugfsMarcel Holtmann2015-04-021-4/+31
| | | | | | | | | When ECDH selftest is enabled, then besides printing the result into the kernel message buffer, also create a debugfs file that allows retrieving the same information. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Restrict BNEP flags to only valid onesMarcel Holtmann2015-04-021-1/+11
| | | | | | | | The BNEP flags should be clearly restricted to valid ones. So this puts extra checks in place to ensure this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Restrict HIDP flags to only valid onesMarcel Holtmann2015-04-021-1/+10
| | | | | | | | The HIDP flags should be clearly restricted to valid ones. So this puts extra checks in place to ensure this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Restrict CMTP flags to only valid onesMarcel Holtmann2015-04-021-1/+10
| | | | | | | | The CMTP flags should be clearly restricted to valid ones. So this puts extra checks in place to ensure this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose current Device ID information via debugfsMarcel Holtmann2015-04-021-0/+26
| | | | | | | | For debugging purposes it is good to be able to read the current configured Device ID details. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Refactor HCI request variables into own structJohan Hedberg2015-03-304-12/+12
| | | | | | | | | | In order to shrink the size of bt_skb_cb, this patch moves the HCI request related variables into their own req_ctrl struct. Additionall the L2CAP and HCI request structs are placed inside the same union since they will never be used at the same time for the same skb. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Refactor L2CAP variables into l2cap_ctrlJohan Hedberg2015-03-303-28/+28
| | | | | | | | | | | We're getting very close to the maximum possible size of bt_skb_cb. To prepare to shrink the struct with the help of a union this patch moves all L2CAP related variables into the l2cap_ctrl struct. To later add other 'ctrl' structs the L2CAP one is renamed simple 'l2cap' instead of 'control'. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove superfluous extra empty line between functionsMarcel Holtmann2015-03-291-1/+0
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix error returns for Read Local OOB Extended Data commandsMarcel Holtmann2015-03-291-37/+34
| | | | | | | | | | | | The Read Local OOB Extended Data commands are required to return the address type and the data length at least. However currently the error returns only the address type. To fix this and avoid any extra allocations or stack memory, rearrange the code so that the same path can be used for error returns. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Move memory location outside of hci_dev lockMarcel Holtmann2015-03-291-8/+6
| | | | | | | | | Taking the hci_dev lock for just a memory allocation seems a bit too much and not really needed. So instead try to allocate the memory first and then take the lock. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Update adv. parameters when conn. setting changesArman Uguray2015-03-281-1/+2
| | | | | | | | | This patch fixes a bug where the advertising parameters weren't updated after a call to "Set Connectable" if the HCI_ADVERTISING_INSTANCE setting was set. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use ADV_SCAN_IND for adv. instancesArman Uguray2015-03-281-1/+20
| | | | | | | | | With this patch, ADV_SCAN_IND will be used for advertising instances that have non-zero scan response data while the global "connectable" setting is "off". Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix using global connectable settings for advArman Uguray2015-03-281-4/+10
| | | | | | | | | This patch fixes a bug where ADV_NONCONN_IND was being used for advertising instances >0 while the global connectable setting was set to "on". Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix race condition with HCI_RESET flagJohan Hedberg2015-03-281-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the HCI init phase a completed request might be the last part of the setup procedure after which the actual init procedure starts. The init procedure begins with a call to hci_reset_req() which sets the HCI_RESET flag. The purpose of this flag is to make us ignore any updates to ncmd/cmd_cnt as long as we haven't received the command complete event for the HCI_Reset. There's a potential race with this however: hci_req_cmd_complete(hdev, opcode, status); if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) { atomic_set(&hdev->cmd_cnt, 1); if (!skb_queue_empty(&hdev->cmd_q)) queue_work(hdev->workqueue, &hdev->cmd_work); } Since the hci_req_cmd_complete() will trigger the completion of the setup stage, it's possible that hci_reset_req() gets called before we try to read ev->ncmd and the HCI_RESET flag. Because of this the cmd_cnt would never be updated and the hci_reset_req() in practice ends up blocking itself. This patch fixes the issue by updating cmd_cnt before notifying the request completion, and then reading it again to determine whether the cmd_work should be queued or not. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Unify advertising data code pathsArman Uguray2015-03-261-91/+64
| | | | | | | | This patch simplifies the code paths for assembling the advertising data used by advertising instances 0 and 1. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Update supported_flags for AD featuresArman Uguray2015-03-261-3/+29
| | | | | | | | | This patch updates the "supported_flags" parameter returned from the "Read Advertising Features" command. Add Advertising will now return an error if an unsupported flag is provided. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Support the "tx-power" adv flagArman Uguray2015-03-261-0/+19
| | | | | | | | This patch adds support for the "tx-power" flag of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Support the "managed-flags" adv flagArman Uguray2015-03-261-2/+9
| | | | | | | | This patch adds support for the "managed-flags" flag of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Support the "limited-discoverable" adv flagArman Uguray2015-03-261-1/+8
| | | | | | | | This patch adds support for the "limited-discoverable" flag of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Support the "discoverable" adv flagArman Uguray2015-03-261-8/+30
| | | | | | | | This patch adds support for the "discoverable" flag of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Support the "connectable mode" adv flagArman Uguray2015-03-261-31/+56
| | | | | | | | This patch adds support for the "connectable mode" flag of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix minor typo in comment for static address settingMarcel Holtmann2015-03-261-1/+1
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Filter list of supported commands/events for untrusted usersMarcel Holtmann2015-03-251-7/+46
| | | | | | | | | | | | | When the user of the management interface is not trusted, then it only has access to a limited set of commands and events. When providing the list of supported commands and events take the trusted vs untrusted status of the user into account and return different lists. This way the untrusted user knows exactly which commands it can execute and which events it can receive. So no guesswork needed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add support for adv instance timeoutArman Uguray2015-03-241-20/+81
| | | | | | | | This patch implements support for the timeout parameter of the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for instance scan responseArman Uguray2015-03-241-14/+52
| | | | | | | | This patch implements setting the Scan Response data provided as part of an advertising instance through the Add Advertising command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement the Remove Advertising commandArman Uguray2015-03-241-0/+103
| | | | | | | This patch implements the "Remove Advertising" mgmt command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement the Add Advertising commandArman Uguray2015-03-241-10/+273
| | | | | | | | | | | | This patch adds the most basic implementation for the "Add Advertisement" command. All state updates between the various HCI settings (POWERED, ADVERTISING, ADVERTISING_INSTANCE, and LE_ENABLED) has been implemented. The command currently supports only setting the advertising data fields, with no flags and no scan response data. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 03:25:40 +0100