- 23 1月, 2013 4 次提交
-
-
由 Johan Hedberg 提交于
Failures of mgmt commands should be indicated with valid mgmt status codes, and EINVAL is not one of them. Instead MGMT_STATUS_INVALID_PARAMS should be returned. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The debug_keys parameter is only allowed to have the values 0x00 and 0x01. Any other value should result in a proper command status with MGMT_STATUS_INVALID_PARAMS. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Szymon Janc 提交于
According to Bluetooth Management API specification Pair Device Command should generate command complete event on both success and failure. This fix replying with command status (which lacks address info) when adapter is powered off. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
When a HCI device is powered off the Management interface specification dictates that the class of device value is indicated as zero. This patch fixes sending of the appropriate class of device changed event when a HCI device is powered off. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 18 1月, 2013 3 次提交
-
-
由 Johan Hedberg 提交于
There's a per-HCI device workqueue (hdev->workqueue) that should be used for general per-HCI device work (except hdev->req_workqueue that's for hci_request() related work). This patch fixes places using the system-global work queue and makes them use the hdev->workqueue instead. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch converts work assignment relying on hci_request() from the system-global work queue to the per-HCI device specific work queue (hdev->req_workqueue) intended for hci_request() related tasks. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The hci_request function is blocking and cannot be called through the usual per-HCI device workqueue (hdev->workqueue). While hci_request is in progress any other work from the queue, including sending HCI commands to the controller would be blocked and eventually cause the hci_request call to time out. This patch adds a second workqueue to be used by operations needing hci_request and thereby avoiding issues with blocking other workqueue users. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 11 1月, 2013 3 次提交
-
-
由 Gustavo Padovan 提交于
The uuid should be printed in the CPU endianness and not in little-endian. Acked-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The socket from which a mgmt_set_powered command was received should only receive the command response but no new_settings event. The mgmt_powered() function which is used to handle the situation with the HCI_AUTO_OFF flag tries to check for a pending command to know which socket to skip the event for, but since the pending command hasn't been added this will not happen. This patch fixes the issue by adding the pending command for the HCI_AUTO_OFF case and thereby ensures that mgmt_powered() will skip the right socket when sending the new_settings event, but still send the proper response to the socket where the command came from. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
Management commands should whenever possible fail with proper command status or command complete events. This patch fixes the mgmt_start_discovery command to do this for the failure cases where an incorrect parameter value was passed to it ("not supported" if the parameter value was valid but the controller doesn't support it and "invalid params" if it isn't valid at all). Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 10 1月, 2013 13 次提交
-
-
由 Johan Hedberg 提交于
All mgmt_set_* commands that take a boolean value encoded in the form of a byte should only accept the values 0x00 and 0x01. This patch adds the necessary checks for this and returns "invalid params" responses if anything else is provided as the value. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
This patch fixes sections of code that do not need hci_lock_dev to be outside of the lock. Such sections include code that do not touch the hdev at all as well as sections which just read a single byte from the supported_features value (i.e. all lmp_*_capable() macros). Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The concept of Class of Device only exists for BR/EDR controllers. The mgmt_set_dev_class command should therefore return a proper "not supported" error if it is attempted for a controller that doesn't support BR/EDR (e.g. a single mode LE-only one). Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
The two lowest bits of the minor device class value are reserved and should be zero, and the three highest bits of the major device class likewise. The management code should therefore test for this and return a proper "invalid params" error if the condition is not met. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
All management events are expected to indicate successful completion through a command complete event, however the load long term keys command was missing this. This patch adds the missing event. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Johan Hedberg 提交于
All management commands are expected to indicate successful completion through a command complete event however the confirm name command was missing it. This patch add the sending of the missing event. Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Szymon Janc 提交于
Use MGMT_STATUS_SUCCESS for success return code. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Szymon Janc 提交于
Those commands don't send any HCI commands to controller so there is no need to restrict them to only powered up controller. This also makes implementation more consistent as already stored remote OOB data persist power toggle. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Using bit operations solves problems with multiple requests and clearing state. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Remove code which cannot execute. l2cap_conn_add for AMP_LINK might only be invoked when receiving data in l2cap_recv_acldata. But this case is checked in the first statement there. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Use chan->hs_hcon instead of lookup by dst address. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Postpone sending A2MP Create Phylink Response until we got successful HCI Command Complete after HCI Write Remote AMP Assoc. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Rami Rosen 提交于
This patch removes unnecessary include of <net/bluetooth/l2cap.h> in bluetooth/bnep/core.c. Signed-off-by: NRami Rosen <ramirose@gmail.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 07 12月, 2012 1 次提交
-
-
由 Lamarque V. Souza 提交于
This patch against kernel 3.7.0-rc8 fixes a kernel oops when turning on the bluetooth mouse with id 0458:0058 [1]. The mouse in question supports both input and hid sessions, however it is blacklisted in drivers/hid/hid-core.c so the input session is one that should be used. Long ago (around kernel 3.0.0) some changes in the bluetooth subsystem made the kernel do not fallback to input session when hid session is not supported or blacklisted. This patch restore that behaviour by making the kernel try the input session if hid_add_device returns ENODEV. The patch exports hid_ignore() from hid-core.c so that it can be used in the bluetooth subsystem. [1] https://bugzilla.kernel.org/show_bug.cgi?id=39882Signed-off-by: NLamarque V. Souza <lamarque@gmail.com> Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 04 12月, 2012 12 次提交
-
-
由 Gustavo Padovan 提交于
This reverts commit 269c4845. The commit was causing dead locks and NULL dereferences in the sco code: [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7] [28084.104021] Modules linked in: btusb bluetooth <snip [last unloaded: bluetooth] ... [28084.104021] [<c160246d>] _raw_spin_lock+0xd/0x10 [28084.104021] [<f920e708>] sco_conn_del+0x58/0x1b0 [bluetooth] [28084.104021] [<f920f1a9>] sco_connect_cfm+0xb9/0x2b0 [bluetooth] [28084.104021] [<f91ef289>] hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth] [28084.104021] [<f91f1a8d>] hci_event_packet+0x74d/0x2b40 [bluetooth] [28084.104021] [<c1501abd>] ? __kfree_skb+0x3d/0x90 [28084.104021] [<c1501b46>] ? kfree_skb+0x36/0x90 [28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] [28084.104021] [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] Cc: stable@vger.kernel.org Reported-by: NChan-yeol Park <chanyeol.park@gmail.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Make code more readable by changing CONF_NO_FCS_RECV which is read as "No L2CAP FCS option received" to CONF_RECV_NO_FCS which means "Received L2CAP option NO_FCS". This flag really means that we have received L2CAP FRAME CHECK SEQUENCE (FCS) OPTION with value "No FCS". Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Process L2CAP Config rsp Pending with FCS Option 0x00 (No FCS) which is sent by Motorola Windows 7 Bluetooth stack. The trace is shown below (all other options are skipped). ... < ACL data: handle 1 flags 0x00 dlen 48 L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 36 ... FCS Option 0x00 (No FCS) > ACL data: handle 1 flags 0x02 dlen 48 L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 36 ... FCS Option 0x01 (CRC16 Check) < ACL data: handle 1 flags 0x00 dlen 47 L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 4 clen 33 Pending ... > ACL data: handle 1 flags 0x02 dlen 50 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 4 clen 36 Pending ... FCS Option 0x00 (No FCS) < ACL data: handle 1 flags 0x00 dlen 14 L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 0 Success > ACL data: handle 1 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0 Success ... Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
If L2CAP_FEAT_FCS is not supported we sould miss EWS option configuration because of break. Make code more readable by combining FCS configuration in the single block. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Before starting quering remote AMP controllers make sure that there is local active AMP controller. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
After getting HCIDEVDOWN controller did not mark itself as 0x00 which means: "The Controller radio is available but is currently physically powered down". The result was even if the hdev was down we return in controller list value 0x01 "status 0x01 (Bluetooth only)". Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
l2cap_send_disconn_req takes 3 parameters of which conn might be derived from chan. Make this conversion inside l2cap_send_disconn_req. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
Some comparisons needs to double negation(!!) in order to make the value of the field boolean. Add it to the macro makes the code more readable. Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Frédéric Dalleau 提交于
In order to authenticate and configure an incoming SCO connection, the BT_DEFER_SETUP option was added. This option is intended to defer reply to Connect Request on SCO sockets. When a connection is requested, the listening socket is unblocked but the effective connection setup happens only on first recv. Any send between accept and recv fails with -ENOTCONN. Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Frédéric Dalleau 提交于
This option will set the BT_SK_DEFER_SETUP bit in socket flags. Signed-off-by: NFrédéric Dalleau <frederic.dalleau@linux.intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
We need to cancel the hci_power_on work in order to avoid it run when we try to free the hdev. [ 1434.201149] ------------[ cut here ]------------ [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0() [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci _power_on+0x0/0x90 [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next- 20121112-sasha-00018-g2f4ce0e #127 [ 1434.210760] Call Trace: [ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0 [ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0 [ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50 [ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0 [ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310 [ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0 [ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230 [ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20 [ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20 [ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330 [ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20 [ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0 [ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190 [ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10 [ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60 [ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20 [ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30 [ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60 [ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250 [ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0 [ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10 [ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0 [ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0 [ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17 [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]--- Cc: stable@vger.kernel.org Reported-by: NSasha Levin <sasha.levin@oracle.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Gustavo Padovan 提交于
This patch fixes the following report, it happens when accepting rfcomm connections: [ 228.165378] ============================================= [ 228.165378] [ INFO: possible recursive locking detected ] [ 228.165378] 3.7.0-rc1-00536-gc1d5dc4a #120 Tainted: G W [ 228.165378] --------------------------------------------- [ 228.165378] bluetoothd/1341 is trying to acquire lock: [ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth] [ 228.165378] [ 228.165378] but task is already holding lock: [ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at: [<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm] [ 228.165378] [ 228.165378] other info that might help us debug this: [ 228.165378] Possible unsafe locking scenario: [ 228.165378] [ 228.165378] CPU0 [ 228.165378] ---- [ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); [ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM); [ 228.165378] [ 228.165378] *** DEADLOCK *** [ 228.165378] [ 228.165378] May be due to missing lock nesting notation Cc: stable@vger.kernel.org Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
- 21 11月, 2012 4 次提交
-
-
由 Szymon Janc 提交于
OOB authentication mechanism should be used only if pairing process has been activated by previous OOB information exchange (Core Spec 4.0 , vol. 1, Part A, 5.1.4.3). Stored OOB data for specific device should be removed if that device was discovered in band later on. Signed-off-by: NSzymon Janc <szymon.janc@tieto.com> Acked-by: NJohan Hedberg <johan.hedberg@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
When receiving L2CAP Create Channel Request set the channel as L2CAP_FCS_NONE. Then in "L2CAP Config req" following field will be set: "FCS Option 0x00 (No FCS)". So by default High Speed channels have no FCS. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
Instead of printing: "[ 7763.082007] Bluetooth: 2" print something like: "[ 7763.082007] Bluetooth: Trailing bytes: 2 in sframe" Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-
由 Andrei Emeltchenko 提交于
local_amp_id is used in l2cap_physical_cfm and shall be set up before calling it. Signed-off-by: NAndrei Emeltchenko <andrei.emeltchenko@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
-