user/sven/linux.git/net/bluetooth, branch v3.8-rc4

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid

2012-12-13T20:00:48Z

Pull HID subsystem updates from Jiri Kosina: 1) Support for HID over I2C bus has been added by Benjamin Tissoires. ACPI device discovery is still in the works. 2) Support for Win8 Multitiouch protocol is being added, most work done by Benjamin Tissoires as well 3) EIO/ERESTARTSYS is fixed in hiddev/hidraw, fixes by Andrew Duggan and Jiri Kosina 4) ION iCade driver added by Bastien Nocera 5) Support for a couple new Roccat devices has been added by Stefan Achatz 6) HID sensor hubs are now auto-detected instead of having to list all the VID/PID combinations in the blacklist array 7) other random fixes and support for new device IDs * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (65 commits) HID: i2c-hid: add mutex protecting open/close race Revert "HID: sensors: add to special driver list" HID: sensors: autodetect USB HID sensor hubs HID: hidp: fallback to input session properly if hid is blacklisted HID: i2c-hid: fix ret_count check HID: i2c-hid: fix i2c_hid_get_raw_report count mismatches HID: i2c-hid: remove extra .irq field in struct i2c_hid HID: i2c-hid: reorder allocation/free of buffers HID: i2c-hid: fix memory corruption due to missing hid declaration HID: i2c-hid: remove superfluous include HID: i2c-hid: remove unneeded test in i2c_hid_remove HID: i2c-hid: i2c_hid_get_report may fail HID: i2c-hid: also call i2c_hid_free_buffers in i2c_hid_remove HID: i2c-hid: fix error messages HID: i2c-hid: fix return paths HID: i2c-hid: remove unused static declarations HID: i2c-hid: fix i2c_hid_dbg macro HID: i2c-hid: fix checkpatch.pl warning HID: i2c-hid: enhance Kconfig HID: i2c-hid: change I2C name ...

Merge branches 'for-3.7/upstream-fixes', 'for-3.8/hidraw', 'for-3.8/i2c-hid', 'for-3.8/multitouch', 'for-3.8/roccat', 'for-3.8/sensors' and 'for-3.8/upstream' into for-linus

2012-12-12T20:41:55Z

Conflicts: drivers/hid/hid-core.c

HID: hidp: fallback to input session properly if hid is blacklisted

2012-12-07T10:12:27Z

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=39882 Signed-off-by: Lamarque V. Souza Acked-by: Gustavo Padovan Signed-off-by: Jiri Kosina

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

2012-12-03T18:46:03Z

Revert "Bluetooth: Fix possible deadlock in SCO code"

2012-12-03T18:00:04Z

This reverts commit 269c4845d5b3627b95b1934107251bacbe99bb68. 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 ] _raw_spin_lock+0xd/0x10 [28084.104021] [] sco_conn_del+0x58/0x1b0 [bluetooth] [28084.104021] [] sco_connect_cfm+0xb9/0x2b0 [bluetooth] [28084.104021] [] hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth] [28084.104021] [] hci_event_packet+0x74d/0x2b40 [bluetooth] [28084.104021] [] ? __kfree_skb+0x3d/0x90 [28084.104021] [] ? kfree_skb+0x36/0x90 [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] [28084.104021] [] ? hci_send_to_monitor+0x10e/0x190 [bluetooth] Cc: stable@vger.kernel.org Reported-by: Chan-yeol Park Signed-off-by: Gustavo Padovan

Bluetooth: trivial: Change NO_FCS_RECV to RECV_NO_FCS

2012-12-03T18:00:01Z

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: Andrei Emeltchenko Signed-off-by: Gustavo Padovan

Bluetooth: Process receiving FCS_NONE in L2CAP Conf Rsp

2012-12-03T18:00:01Z

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: Andrei Emeltchenko Signed-off-by: Gustavo Padovan

Bluetooth: Fix missing L2CAP EWS Conf parameter

2012-12-03T18:00:00Z

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: Andrei Emeltchenko Signed-off-by: Gustavo Padovan

Bluetooth: AMP: Check that AMP is present and active

2012-12-03T18:00:00Z

Before starting quering remote AMP controllers make sure that there is local active AMP controller. Signed-off-by: Andrei Emeltchenko Signed-off-by: Gustavo Padovan

Bluetooth: AMP: Mark controller radio powered down after HCIDEVDOWN

2012-12-03T17:59:59Z

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: Andrei Emeltchenko Signed-off-by: Gustavo Padovan