summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2013-10-15Bluetooth: Access sk_sndtimeo indirectly in l2cap_core.cGustavo Padovan
As part of the work to remove struct sock from l2cap_core.c and make it more generic we remove in this commit the direct access to sk->sk_sndtimeo member. This objective of this change is purely remove sk usage from l2cap_core.c Now we have a new l2cap ops to get the current value of sk->sndtimeo. A l2cap_chan_no_get_sndtimeo was added for users of L2CAP that doesn't need to set a timeout. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-15Bluetooth: Add l2cap_state_change_and_error()Gustavo Padovan
l2cap_state_change_and_error() introduces the ability to update a l2cap_user with changes in channel's state and error code with just one call. The main reason for this is to avoid race conditions between and setting the state and then the error. Otherwise we would need to release the lock between both operations. This is another step of an ongoing work to make l2cap_core.c totally independent from l2cap's struct sock. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-15Bluetooth: Extend state_change() call to report errors tooGustavo Padovan
Instead of creating an new function pointer to report errors we are just reusing state_change for that and there is a simple reason for this, one place in the l2cap_core.c code needs, in a locked sk, set both the sk_state and sk_err. If we create two different functions for this we would need to release the lock between the two operation putting the socket in non desired state. The change is transparent to the l2cap_core.c code, user that only needs to set the state won't need any modification. This is another step of an ongoing work to make l2cap_core.c totally independent from l2cap's struct sock. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-15Bluetooth: Update class of device on discoverable timeoutMarcel Holtmann
When the discoverable timeout triggers and limited discoverable mode was used, then the class of device needs to be updated to remove the limited discoverable bit. To keep the class of device logic in a central place, expose a new function mgmt_discoverable_timeout that can be called from the timeout callback. In case the class of device value needs updating, it will add the HCI command to the transaction. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Move eir_get_length() function into hci_event.cMarcel Holtmann
The eir_get_length() function is only used from hci_event.c and so instead of having a public function move it to the location where it is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Move eir_append_data() function into mgmt.cMarcel Holtmann
The eir_append_data() function is only used from mgmt.c and so instead of having a public function move it to the location where it is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Make mgmt_new_link_key() return voidMarcel Holtmann
The return value of mgmt_new_link_key() function is not used and so just change it to return void. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Add support for entering limited discoverable modeMarcel Holtmann
The limited discoverable mode should be used when a device is only discoverable for a certain amount of time and after that it returns back into being non-discoverable. This adds another option to the set discoverable management command to clearly distinguish limited discoverable from general discoverable mode. While the general discoverable mode can be set with a specific timeout or as permanent setting, the limited discoverable mode requires a timeout. The timeout is flexible and the kernel will not enforce any specific limitations. That GAP part of this is required by userspace to enforce according to the Bluetooth core specification. Devices in limited discoverable mode can still be found by the general discovery procedure. It is mandatory that a device sets both GIAC and LIAC when entering limited discoverable mode. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Add HCI command structure for writing current IAC LAPMarcel Holtmann
This patch just adds the HCI command structure for configuring the current IAC LAP setting. The length of the command is variable and supports more than two IAC. However since there is only general discoverable and limited discoverable modes, this can be limited to two possible IACs. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Simplify the code for re-arming discoverable timeoutMarcel Holtmann
When only the discoverable timeout gets updated, just cancel the current timeout, store the new timeout value. If the new timeout is valid, then arm the discoverable timeout again. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Move arming of discoverable timeout to complete handlerMarcel Holtmann
The discoverable timeout is currently armed from hci_event.c and causes some side effects when using HCI commands instead of the management interface. To make this clear, only arm the discoverable timeout from the management command complete handler. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Update class of device after changing discoverable modeMarcel Holtmann
When the discoverable mode gets changed, ensure that the class of device value has the correct limited discoverable bit value set. Since the class of device HCI command will only be send to the controller when the value changes, it is safe to just always trigger the update. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Make mgmt_write_scan_failed() return voidMarcel Holtmann
The return value of mgmt_write_scan_failed() function is not used and so just change it to return void. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Make mgmt_connectable() return voidMarcel Holtmann
The return value of mgmt_connectable() function is not used and so just change it to return void. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Make mgmt_discoverable() return voidMarcel Holtmann
The return value of mgmt_discoverable() function is not used and so just change it to return void. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Introduce flag for limited discoverable modeMarcel Holtmann
Add a new flag that can be set when in limited discoverable mode. This flag will cause the limited discoverable bit in the class of device value to bet set. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Update advertising data based on management commandsMarcel Holtmann
Magically updating the advertising data when some random command enables advertising in the controller is not really a good idea. It also caused a bit of complicated code with the exported hci_udpate_ad function that is shared from many places. This patch consolidates the advertising data update into the management core. It also makes sure that when powering on with LE enabled or later on enabling LE the controller has a good default for advertising data. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Use hci_request for discoverable timeout handlingMarcel Holtmann
When the discoverable timeout triggers and it is time to turn inquiry scan back off, use the HCI request framework to do it. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-15Bluetooth: Fix minor coding style issue in set_connectable()Marcel Holtmann
There is a minor coding style violation and so just fix it. No actual logic has changed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-14Bluetooth: Read current IAC LAP on controller setupMarcel Holtmann
Read the current IAC LAP values when initializing the controller. The values are not used, but it is good to have them in the trace files for debugging purposes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-10-14Bluetooth: Read number of supported IAC on controller setupMarcel Holtmann
When initializing a controller make sure to read out the number of supported IAC and store its result. This value is needed to determine if limited discoverable for BR/EDR can be configured or not. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
2013-10-14Bluetooth: Check that scan window is smaller or equal than scan intervalMarcel Holtmann
The scan window parameter for connection establishment and passive scanning needs to be smaller or equal than the scan interval. Instead of waiting for a controller to reject these values later on, just reject them right away. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-14Bluetooth: Check that bind() bdaddr type matches connect()Johan Hedberg
If a socket was bound to an address type other than BR/EDR (such as LE) we should reject trying to connect it to a BR/EDR address. The same applies for binding to BR/EDR and trying to connect to non-BR/EDR. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Reject invalid bdaddr types for socketsJohan Hedberg
We need to verify that the bdaddr type passed to connect() and bind() is within the set of valid values. If it is not we need to cleanly fail with EINVAL. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Convert Set Discoverable to use an asynchronous requestJohan Hedberg
This patch converts Set Discoverable to use an asynchronous request along with its own completion callback. This is necessary for splitting raw HCI socket use cases from mgmt, as well as for enabling the hooking up of Advertising parameters together with the HCI_DISCOVERABLE flag (coming in later patches). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Fix updating scan mode in set_bredr()Johan Hedberg
Now that the connectable setting is also applicable for the LE side it's possible that the HCI_CONNECTABLE flag is already set when changing the BR/EDR setting from false to true while the controller is powered. In this situation we need to update the BR/EDR scan mode to reflect the setting. Additionally, since HCI_CONNECTABLE also applies to LE we must not clear the HCI_CONNECTABLE flag when disabling bredr. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Move set_bredr_scan() to avoid forward declarationJohan Hedberg
The set_bredr_scan() function will soon be needed by the set_bredr() function, so move it to a new location to avoid having to add a forward declaration. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Make Set Connectable also update the LE advertising typeJohan Hedberg
This patch updates the Set Connectable Management command to also update the LE advertising type to either connectable or non-connectable advertising. An extra helper function is needed for getting the right advertising type since we can not only rely on the HCI_CONNECTABLE flag but must also check for a pending Set Connectable command (in which case the flag does not yet have its final value). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Fix updating advertising data needlesslyJohan Hedberg
We need to ensure that the advertising data is up-to-date whenever advertising is enabled, but when disabling advertising we do not need to worry about it (since it will eventually get fixed as soon as advertising is enabled again). This patch fixes this in the command complete callback for set_adv_enable. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Move static advertising functions to avoid forward declarationsJohan Hedberg
These functions will soon be used by set_connectable() so move them to a location in mgmt.c that doesn't require forward declarations. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Add missing error handling for Set ConnectableJohan Hedberg
If the HCI commands related to the Set Connectable command fail we will get a non-zero status in the request completion callback. In such a case we must respond with the appropriate command status message to user space. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Move more logic into set_connectable complete callbackJohan Hedberg
This patch moves the responsibility of setting/clearing the HCI_CONNECTABLE flag to the request completion callback of the Set Connectable command. This will allow us to cleanly add support for LE Advertising hooks in later patches. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Reorganize set_connectable HCI command sendingJohan Hedberg
This patch moves all the decisions of which HCI commands to send (or not to send) to the code between hci_req_init() and hci_req_run() this allows us to further extend the request with further commands but still keep the same logic of handling whether to return a direct mgmt response in the case that no HCI commands were sent. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2013-10-14Bluetooth: Introduce L2CAP channel callback for resumingMarcel Holtmann
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing a dependency on the socket. So intead of doing that, use a channel callback into the socket handling to resume. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-14Bluetooth: Introduce L2CAP channel flag for defer setupMarcel Holtmann
The L2CAP core should not look into the socket flags to figure out the setting of defer setup. So introduce a L2CAP channel flag that mirrors the socket flag. Since the defer setup option is only set in one place this becomes a really easy thing to do. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-14Bluetooth: Adjust header for proc socket informationMarcel Holtmann
The exposed socket information do not contain source or destination addresses. So adjust the header accordingly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Increase minor version of core moduleMarcel Holtmann
There have been a lot of changes in the core Bluetooth handling lately. So it is a good idea to increase the module version. The module version is not used anywhere, but it makes debugging a little bit simpler if versions can be distinguished. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Provide msg_name callback for L2CAP connectionless channelsMarcel Holtmann
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need to receive the remote BD_ADDR and PSM information via msg_name from the recvmsg() system call. So in case the L2CAP socket is for connectionless channels, provide a msg_name callback that can update the data. Also store the remote BD_ADDR and PSM in the skb so it can be extracted later on. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Add support for per socket msg_name callbackMarcel Holtmann
This allows to add a per socket msg_name callback that can be used for updating the msg_name information for recvmsg() system calls. This feature is used by another patch to support address information on L2CAP connectionless channels. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Use l2cap_pi(sk) directly where possibleMarcel Holtmann
There are few places where it makes sense to use l2cap_pi(sk) directly instead of assigning it to temporary structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Remove src and dst fields from bt_sock structureMarcel Holtmann
Every socket protocol now stores its own address information. So just remove the generic src and dst fields since they are no longer needed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Store RFCOMM address information in its own socket structureMarcel Holtmann
The address information of RFCOMM sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Store SCO address information in its own socket structureMarcel Holtmann
The address information of SCO sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Use SCO addresses from HCI connection directlyMarcel Holtmann
Instead of storing a pointer to the addresses for the HCI device and HCI connection, use them directly. With the recent changes to address tracking of HCI connections, this becomes simple. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Access BNEP session addresses through L2CAP channelMarcel Holtmann
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Access HIDP session addresses through L2CAP channelMarcel Holtmann
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Access CMTP session addresses through L2CAP channelMarcel Holtmann
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Access RFCOMM session addresses through L2CAP channelMarcel Holtmann
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Return the correct address type for L2CAP socketsMarcel Holtmann
The L2CAP sockets can use BR/EDR public, LE public and LE random addresses for various combinations of source and destination devices. So make sure that getsockname(), getpeername() and accept() return the correct address type. For this the address type of the source and destination is stored with the L2CAP channel information. The stored address type is not the one specific for the HCI protocol. It is the address type used for the L2CAP sockets and the management interface. The underlying HCI connections store the HCI address type. If needed, it gets converted to the socket address type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2013-10-13Bluetooth: Store address information in L2CAP channel structureMarcel Holtmann
With the effort of abstracting the L2CAP socket from the underlying L2CAP channel it is important to store the source and destination address information directly in the L2CAP channel structure. Direct access to the HCI connection address information is not possible since they might not be avaiable at L2CAP channel creation time. The address information will be updated when the underlying BR/EDR or LE connection status changes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>