pm24.git/net/bluetooth, branch v3.19-rc7

Bluetooth: Fix accepting connections when not using mgmt

2014-12-24T19:02:00Z

When connectable mode is enabled (page scan on) through some non-mgmt method the HCI_CONNECTABLE flag will not be set. For backwards compatibility with user space versions not using mgmt we should not require HCI_CONNECTABLE to be set if HCI_MGMT is not set. Reported-by: Pali Rohár Tested-by: Pali Rohár Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org # 3.17+

Bluetooth: Fix controller configuration with HCI_QUIRK_INVALID_BDADDR

2014-12-24T18:35:46Z

When controllers set the HCI_QUIRK_INVALID_BDADDR flag, it is required by userspace to program a valid public Bluetooth device address into the controller before it can be used. After successful address configuration, the internal state changes and the controller runs the complete initialization procedure. However one small difference is that this is no longer the HCI_SETUP stage. The HCI_SETUP stage is only valid during initial controller setup. In this case the stack runs the initialization as part of the HCI_CONFIG stage. The controller version information, default name and supported commands are only stored during HCI_SETUP. While these information are static, they are not read initially when HCI_QUIRK_INVALID_BDADDR is set. So when running in HCI_CONFIG state, these information need to be updated as well. This especially impacts Bluetooth 4.1 and later controllers using extended feature pages and second event mask page. Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg Cc: stable@vger.kernel.org # 3.17+

Bluetooth: bnep: bnep_add_connection() should verify that it's dealing with l2cap socket

2014-12-19T12:48:27Z

same story as cmtp Signed-off-by: Al Viro Signed-off-by: Marcel Holtmann

Bluetooth: cmtp: cmtp_add_connection() should verify that it's dealing with l2cap socket

2014-12-19T12:48:21Z

... rather than relying on ciptool(8) never passing it anything else. Give it e.g. an AF_UNIX connected socket (from socketpair(2)) and it'll oops, trying to evaluate &l2cap_pi(sock->sk)->chan->dst... Signed-off-by: Al Viro Signed-off-by: Marcel Holtmann

Bluetooth: hidp_connection_add() unsafe use of l2cap_pi()

2014-12-19T12:40:07Z

it's OK after we'd verified the sockets, but not before that. Signed-off-by: Al Viro Signed-off-by: Marcel Holtmann

Bluetooth: 6lowpan: Do not free skb when packet is dropped

2014-12-19T12:39:50Z

If we need to drop the message because of some error in the compression etc, then do not free the skb as that is done automatically in other part of networking stack. Signed-off-by: Jukka Rissanen Signed-off-by: Marcel Holtmann

Bluetooth: Fix bug with filter in service discovery optimization

2014-12-17T20:03:49Z

The optimization for filtering out extended inquiry results, advertising reports or scan response data based on provided UUID list has a logic bug. In case no match is found in the advertising data, the scan response is ignored and not checked against the filter. This will lead to events being filtered wrongly. Change the code to actually only drop the events when the scan response data is not present. If it is present, it needs to be checked against the provided filter. The patch is a bit more complex than it needs to be. That is because it also fixes this compiler warning that some gcc versions produce. CC net/bluetooth/mgmt.o net/bluetooth/mgmt.c: In function ‘mgmt_device_found’: net/bluetooth/mgmt.c:7028:7: warning: ‘match’ may be used uninitialized in this function [-Wmaybe-uninitialized] bool match; ^ It seems that gcc can not clearly figure out the context of the match variable. So just change the branches for the extended inquiry response and advertising data around so that it is clear. Reported-by: Geert Uytterhoeven Signed-off-by: Marcel Holtmann Signed-off-by: Johan Hedberg

Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next

2014-12-15T18:23:09Z

Bluetooth: Fix mgmt response status when removing adapter

2014-12-12T12:20:12Z

When an adapter is removed (hci_unregister_dev) any pending mgmt commands for that adapter should get the appropriate INVALID_INDEX response. Since hci_unregister_dev() calls hci_dev_do_close() first that'd so far have caused "not powered" responses to be sent. Skipping the HCI_UNREGISTER case in mgmt_powered() is also not a solution since before reaching the mgmt_index_removed() stage any hci_conn callbacks (e.g. used by pairing) will get called, thereby causing "disconnected" status responses to be sent. The fix that covers all scenarios is to handle both INVALID_INDEX and NOT_POWERED responses through the mgmt_powered() function. The INVALID_INDEX response sending from mgmt_index_removed() is left untouched since there are a couple of places not related to powering off or removing an adapter that call it (e.g. configuring a new bdaddr). Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann

Bluetooth: Fix enabling BR/EDR SC when powering on

2014-12-12T12:17:41Z

If we're in the AUTO_OFF stage the powered_update_hci() function is responsible for doing the updates to the HCI state that were not done during the actual mgmt command handlers. One of the updates needing done is for BR/EDR SC support. This patch adds the missing HCI command for SC support to the powered_update_hci() function. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann