aboutsummaryrefslogtreecommitdiffstats
path: root/net/bluetooth/hci_event.c
Commit message (Collapse)AuthorAge
* Bluetooth: Defer SCO setup if mode change is pendingMarcel Holtmann2010-07-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Certain headsets such as the Motorola H350 will reject SCO and eSCO connection requests while the ACL is transitioning from sniff mode to active mode. Add synchronization so that SCO and eSCO connection requests will wait until the ACL has fully transitioned to active mode. < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2 handle 12 > HCI Event: Command Status (0x0f) plen 4 Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 12 voice setting 0x0040 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 12 packets 1 > HCI Event: Mode Change (0x14) plen 6 status 0x00 handle 12 mode 0x00 interval 0 Mode: Active > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x10 handle 14 bdaddr 00:1A:0E:50:28:A4 type SCO Error: Connection Accept Timeout Exceeded Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix typo in hci_event.cGustavo F. Padovan2010-07-21
| | | | | | | memmory -> memory Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Reassigned copyright to Code Aurora ForumRon Shaffer2010-07-21
| | | | | | | | | Qualcomm, Inc. has reassigned rights to Code Aurora Forum. Accordingly, as files are modified by Code Aurora Forum members, the copyright statement will be updated. Signed-off-by: Ron Shaffer <rshaffer@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add blacklist support for incoming connectionsJohan Hedberg2010-07-21
| | | | | | | | | | | In some circumstances it could be desirable to reject incoming connections on the baseband level. This patch adds this feature through two new ioctl's: HCIBLOCKADDR and HCIUNBLOCKADDR. Both take a simple Bluetooth address as a parameter. BDADDR_ANY can be used with HCIUNBLOCKADDR to remove all devices from the blacklist. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Reset the security level after an authentication failureJohan Hedberg2010-07-08
| | | | | | | | | | When authentication fails for a connection the assumed security level should be set back to BT_SECURITY_LOW so that subsequent connect attempts over the same link don't falsely assume that security is adequate enough. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add SCO fallback for unsupported feature errorStephen Coe2010-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bluetooth SIG PTS test case: TC_AG_ACS_BV_10_I, rejects eSCO with "Unsupported Feature or Parameter Value" (0x11). This patch adds case for SCO fallback. 2007-09-20 12:20:37.787747 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 38 packets 1 2007-09-20 12:20:37.842154 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 38 voice setting 0x0060 2007-09-20 12:20:37.847037 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 2007-09-20 12:20:37.855233 > HCI Event: Max Slots Change (0x1b) plen 3 handle 38 slots 1 2007-09-20 12:20:39.913354 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x11 handle 38 bdaddr 00:16:93:01:01:7A type eSCO Error: Unsupported Feature or Parameter Value 2007-09-20 12:20:39.922629 > HCI Event: Max Slots Change (0x1b) plen 3 handle 38 slots 5 2007-09-20 12:20:58.126886 < ACL data: handle 38 flags 0x02 dlen 8 L2CAP(d): cid 0x0041 len 4 [psm 0] 0000: 0b 53 01 b8 .S.. 2007-09-20 12:20:58.130138 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 38 packets 1 Signed-off-by: Stephen Coe <smcoe1@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fallback eSCO to SCO on error 0x1a (Unsupported Remote Feature)Nick Pelly2010-02-03
| | | | | | | | | | | | | | | | | General Motors carkits that use LGE BT chipsets return this error code when an eSCO is attempted, despite advertising eSCO support. 2009-08-13 14:41:39.755518 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 1 voice setting 0x0060 2009-08-13 14:41:39.757563 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 2009-08-13 14:41:39.789484 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x1a handle 257 bdaddr 00:1E:B2:23:5E:B3 type eSCO Error: Unsupported Remote Feature / Unsupported LMP Feature Signed-off-by: Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Nick Pelly <npelly@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Unobfuscate tasklet_schedule usageMarcel Holtmann2009-12-03
| | | | | | | The tasklet schedule function helpers are just an obfuscation. So remove them and call the schedule functions directly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add extra device reference counting for connectionsMarcel Holtmann2009-08-22
| | | | | | | | | | | | | | | | | | | | The device model itself has no real usable reference counting at the moment and this causes problems if parents are deleted before their children. The device model itself handles the memory details of this correctly, but the uevent order is not consistent. This causes various problems for systems like HAL or even X. So until device_put() does a proper cleanup, the device for Bluetooth connection will be protected with an extra reference counting to ensure the correct order of uevents when connections are terminated. This is not an automatic feature. Higher Bluetooth layers like HIDP or BNEP should grab this new reference to ensure that their uevents are send before the ones from the parent device. Based on a report by Brian Rogers <brian@xyzw.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Don't trigger disconnect timeout for security mode 3 pairingMarcel Holtmann2009-05-09
| | | | | | | | | | | | | | | | | | | | A remote device in security mode 3 that tries to connect will require the pairing during the connection setup phase. The disconnect timeout is now triggered within 10 milliseconds and causes the pairing to fail. If a connection is not fully established and a PIN code request is received, don't trigger the disconnect timeout. The either successful or failing connection complete event will make sure that the timeout is triggered at the right time. The biggest problem with security mode 3 is that many Bluetooth 2.0 device and before use a temporary security mode 3 for dedicated bonding. Based on a report by Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
* Bluetooth: Add different pairing timeout for Legacy PairingMarcel Holtmann2009-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bluetooth stack uses a reference counting for all established ACL links and if no user (L2CAP connection) is present, the link will be terminated to save power. The problem part is the dedicated pairing when using Legacy Pairing (Bluetooth 2.0 and before). At that point no user is present and pairing attempts will be disconnected within 10 seconds or less. In previous kernel version this was not a problem since the disconnect timeout wasn't triggered on incoming connections for the first time. However this caused issues with broken host stacks that kept the connections around after dedicated pairing. When the support for Simple Pairing got added, the link establishment procedure needed to be changed and now causes issues when using Legacy Pairing When using Simple Pairing it is possible to do a proper reference counting of ACL link users. With Legacy Pairing this is not possible since the specification is unclear in some areas and too many broken Bluetooth devices have already been deployed. So instead of trying to deal with all the broken devices, a special pairing timeout will be introduced that increases the timeout to 60 seconds when pairing is triggered. If a broken devices now puts the stack into an unforeseen state, the worst that happens is the disconnect timeout triggers after 120 seconds instead of 4 seconds. This allows successful pairings with legacy and broken devices now. Based on a report by Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add workaround for wrong HCI event in eSCO setupMarcel Holtmann2009-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | The Broadcom chips with 2.1 firmware handle the fallback case to a SCO link wrongly when setting up eSCO connections. < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17 handle 11 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 1 bdaddr 00:1E:3A:xx:xx:xx type SCO encrypt 0x01 The Link Manager negotiates the fallback to SCO, but then sends out a Connect Complete event. This is wrong and the Link Manager should actually send a Synchronous Connection Complete event if the Setup Synchronous Connection has been used. Only the remote side is allowed to use Connect Complete to indicate the missing support for eSCO in the host stack. This patch adds a workaround for this which clearly should not be needed, but reality is that broken Broadcom devices are deployed. Based on a report by Ville Tervo <ville.tervo@nokia.com> Signed-off-by: Marcel Holtman <marcel@holtmann.org>
* Bluetooth: Fallback from eSCO to SCO on unspecified errorMarcel Holtmann2009-04-19
| | | | | | | | | | | | | | | | | | | | | | Some Bluetooth chips (like the ones from Texas Instruments) don't do proper eSCO negotiations inside the Link Manager. They just return an error code and in case of the Kyocera ED-8800 headset it is just a random error. < HCI Command: Setup Synchronous Connection 0x01|0x0028) plen 17 handle 1 voice setting 0x0060 > HCI Event: Command Status (0x0f) plen 4 Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1 > HCI Event: Synchronous Connect Complete (0x2c) plen 17 status 0x1f handle 257 bdaddr 00:14:0A:xx:xx:xx type eSCO Error: Unspecified Error In these cases it is up to the host stack to fallback to a SCO setup and so retry with SCO parameters. Based on a report by Nick Pelly <npelly@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Move hci_conn_del_sysfs() back to avoid device destruct too earlyDave Young2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following commit introduce a regression: commit 7d0db0a373195385a2e0b19d1f5e4b186fdcffac Author: Marcel Holtmann <marcel@holtmann.org> Date: Mon Jul 14 20:13:51 2008 +0200 [Bluetooth] Use a more unique bus name for connections I get panic as following (by netconsole): [ 2709.344034] usb 5-1: new full speed USB device using uhci_hcd and address 4 [ 2709.505776] usb 5-1: configuration #1 chosen from 1 choice [ 2709.569207] Bluetooth: Generic Bluetooth USB driver ver 0.4 [ 2709.570169] usbcore: registered new interface driver btusb [ 2845.742781] BUG: unable to handle kernel paging request at 6b6b6c2f [ 2845.742958] IP: [<c015515c>] __lock_acquire+0x6c/0xa80 [ 2845.743087] *pde = 00000000 [ 2845.743206] Oops: 0002 [#1] SMP [ 2845.743377] last sysfs file: /sys/class/bluetooth/hci0/hci0:6/type [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] [ 2845.743742] Pid: 0, comm: swapper Not tainted (2.6.29-rc5-smp #54) Dell DM051 [ 2845.743742] EIP: 0060:[<c015515c>] EFLAGS: 00010002 CPU: 0 [ 2845.743742] EIP is at __lock_acquire+0x6c/0xa80 [ 2845.743742] EAX: 00000046 EBX: 00000046 ECX: 6b6b6b6b EDX: 00000002 [ 2845.743742] ESI: 6b6b6b6b EDI: 00000000 EBP: c064fd14 ESP: c064fcc8 [ 2845.743742] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 2845.743742] Process swapper (pid: 0, ti=c064e000 task=c05d1400 task.ti=c064e000) [ 2845.743742] Stack: [ 2845.743742] c05d1400 00000002 c05d1400 00000001 00000002 00000000 f65388dc c05d1400 [ 2845.743742] 6b6b6b6b 00000292 c064fd0c c0153732 00000000 00000000 00000001 f700fa50 [ 2845.743742] 00000046 00000000 00000000 c064fd40 c0155be6 00000000 00000002 00000001 [ 2845.743742] Call Trace: [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] ? lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] ? _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] ? skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] ? hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] ? hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] ? hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] ? tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] ? __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] ? do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] ? irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] ? do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] ? common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] ? cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] ? rest_init+0x4e/0x60 [ 2845.743742] Code: 0f 84 69 02 00 00 83 ff 07 0f 87 1e 06 00 00 85 ff 0f 85 08 05 00 00 8b 4d cc 8b 49 04 85 c9 89 4d d4 0f 84 f7 04 00 00 8b 75 d4 <f0> ff 86 c4 00 00 00 89 f0 e8 56 a9 ff ff 85 c0 0f 85 6e 03 00 [ 2845.743742] EIP: [<c015515c>] __lock_acquire+0x6c/0xa80 SS:ESP 0068:c064fcc8 [ 2845.743742] ---[ end trace 4c985b38f022279f ]--- [ 2845.743742] Kernel panic - not syncing: Fatal exception in interrupt [ 2845.743742] ------------[ cut here ]------------ [ 2845.743742] WARNING: at kernel/smp.c:329 smp_call_function_many+0x151/0x200() [ 2845.743742] Hardware name: Dell DM051 [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] Pid: 0, comm: swapper Tainted: G D 2.6.29-rc5-smp #54 [ 2845.743742] Call Trace: [ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0 [ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80 [ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046a3d7>] ? __mutex_unlock_slowpath+0x97/0x160 [ 2845.743742] [<c046a563>] ? mutex_trylock+0xb3/0x180 [ 2845.743742] [<c046a4a8>] ? mutex_unlock+0x8/0x10 [ 2845.743742] [<c015b991>] smp_call_function_many+0x151/0x200 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30 [ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50 [ 2845.743742] [<c012e0f5>] panic+0x55/0x110 [ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0 [ 2845.743742] [<c010668f>] die+0x4f/0x70 [ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610 [ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610 [ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c [ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80 [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] rest_init+0x4e/0x60 [ 2845.743742] ---[ end trace 4c985b38f02227a0 ]--- [ 2845.743742] ------------[ cut here ]------------ [ 2845.743742] WARNING: at kernel/smp.c:226 smp_call_function_single+0x8e/0x110() [ 2845.743742] Hardware name: Dell DM051 [ 2845.743742] Modules linked in: btusb netconsole snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss rfcomm l2cap bluetooth vfat fuse snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm pl2303 snd_timer psmouse usbserial snd 3c59x e100 serio_raw soundcore i2c_i801 intel_agp mii agpgart snd_page_alloc rtc_cmos rtc_core thermal processor rtc_lib button thermal_sys sg evdev [ 2845.743742] Pid: 0, comm: swapper Tainted: G D W 2.6.29-rc5-smp #54 [ 2845.743742] Call Trace: [ 2845.743742] [<c012e076>] warn_slowpath+0x86/0xa0 [ 2845.743742] [<c012e000>] ? warn_slowpath+0x10/0xa0 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c012e661>] ? release_console_sem+0x31/0x1e0 [ 2845.743742] [<c046c8ab>] ? _spin_lock_irqsave+0x6b/0x80 [ 2845.743742] [<c015041b>] ? trace_hardirqs_off+0xb/0x10 [ 2845.743742] [<c046c900>] ? _read_lock_irqsave+0x40/0x80 [ 2845.743742] [<c012e7f2>] ? release_console_sem+0x1c2/0x1e0 [ 2845.743742] [<c0146384>] ? up+0x14/0x40 [ 2845.743742] [<c015b7be>] smp_call_function_single+0x8e/0x110 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c026d23f>] ? cpumask_next_and+0x1f/0x40 [ 2845.743742] [<c015b95a>] smp_call_function_many+0x11a/0x200 [ 2845.743742] [<c010a1a0>] ? stop_this_cpu+0x0/0x40 [ 2845.743742] [<c015ba61>] smp_call_function+0x21/0x30 [ 2845.743742] [<c01137ae>] native_smp_send_stop+0x1e/0x50 [ 2845.743742] [<c012e0f5>] panic+0x55/0x110 [ 2845.743742] [<c01065a8>] oops_end+0xb8/0xc0 [ 2845.743742] [<c010668f>] die+0x4f/0x70 [ 2845.743742] [<c011a8c9>] do_page_fault+0x269/0x610 [ 2845.743742] [<c011a660>] ? do_page_fault+0x0/0x610 [ 2845.743742] [<c046cbaf>] error_code+0x77/0x7c [ 2845.743742] [<c015515c>] ? __lock_acquire+0x6c/0xa80 [ 2845.743742] [<c0153732>] ? trace_hardirqs_on_caller+0x72/0x1c0 [ 2845.743742] [<c0155be6>] lock_acquire+0x76/0xa0 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c046c885>] _spin_lock_irqsave+0x45/0x80 [ 2845.743742] [<c03e1aad>] ? skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1aad>] skb_dequeue+0x1d/0x70 [ 2845.743742] [<c03e1f94>] skb_queue_purge+0x14/0x20 [ 2845.743742] [<f8171f5a>] hci_conn_del+0x10a/0x1c0 [bluetooth] [ 2845.743742] [<f81399c9>] ? l2cap_disconn_ind+0x59/0xb0 [l2cap] [ 2845.743742] [<f81795ce>] ? hci_conn_del_sysfs+0x8e/0xd0 [bluetooth] [ 2845.743742] [<f8175758>] hci_event_packet+0x5f8/0x31c0 [bluetooth] [ 2845.743742] [<c03dfe19>] ? sock_def_readable+0x59/0x80 [ 2845.743742] [<c046c14d>] ? _read_unlock+0x1d/0x20 [ 2845.743742] [<f8178aa9>] ? hci_send_to_sock+0xe9/0x1d0 [bluetooth] [ 2845.743742] [<c015388b>] ? trace_hardirqs_on+0xb/0x10 [ 2845.743742] [<f816fa6a>] hci_rx_task+0x2ba/0x490 [bluetooth] [ 2845.743742] [<c0133661>] ? tasklet_action+0x31/0xc0 [ 2845.743742] [<c013367c>] tasklet_action+0x4c/0xc0 [ 2845.743742] [<c0132eb7>] __do_softirq+0xa7/0x170 [ 2845.743742] [<c0116dec>] ? ack_apic_level+0x5c/0x1c0 [ 2845.743742] [<c0132fd7>] do_softirq+0x57/0x60 [ 2845.743742] [<c01333dc>] irq_exit+0x7c/0x90 [ 2845.743742] [<c01055bb>] do_IRQ+0x4b/0x90 [ 2845.743742] [<c01333d5>] ? irq_exit+0x75/0x90 [ 2845.743742] [<c010392c>] common_interrupt+0x2c/0x34 [ 2845.743742] [<c010a14f>] ? mwait_idle+0x4f/0x70 [ 2845.743742] [<c0101c05>] cpu_idle+0x65/0xb0 [ 2845.743742] [<c045731e>] rest_init+0x4e/0x60 [ 2845.743742] ---[ end trace 4c985b38f02227a1 ]--- [ 2845.743742] Rebooting in 3 seconds.. My logitec bluetooth mouse trying connect to pc, but pc side reject the connection again and again. then panic happens. The reason is due to hci_conn_del_sysfs now called in hci_event_packet, the del work is done in a workqueue, so it's possible done before skb_queue_purge called. I move the hci_conn_del_sysfs after skb_queue_purge just as that before marcel's commit. Remove the hci_conn_del_sysfs in hci_conn_hash_flush as well due to hci_conn_del will deal with the work. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Ask upper layers for HCI disconnect reasonMarcel Holtmann2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the qualification tests demand that in case of failures in L2CAP the HCI disconnect should indicate a reason why L2CAP fails. This is a bluntly layer violation since multiple L2CAP connections could be using the same ACL and thus forcing a disconnect reason is not a good idea. To comply with the Bluetooth test specification, the disconnect reason is now stored in the L2CAP connection structure and every time a new L2CAP channel is added it will set back to its default. So only in the case where the L2CAP channel with the disconnect reason is really the last one, it will propagated to the HCI layer. The HCI layer has been extended with a disconnect indication that allows it to ask upper layers for a disconnect reason. The upper layer must not support this callback and in that case it will nicely default to the existing behavior. If an upper layer like L2CAP can provide a disconnect reason that one will be used to disconnect the ACL or SCO link. No modification to the ACL disconnect timeout have been made. So in case of Linux to Linux connection the initiator will disconnect the ACL link before the acceptor side can signal the specific disconnect reason. That is perfectly fine since Linux doesn't make use of this value anyway. The L2CAP layer has a perfect valid error code for rejecting connection due to a security violation. It is unclear why the Bluetooth specification insists on having specific HCI disconnect reason. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add SCO fallback for eSCO connection attemptsMarcel Holtmann2009-02-27
| | | | | | | | | | | | | | | | | When attempting to setup eSCO connections it can happen that some link manager implementations fail to properly negotiate the eSCO parameters and thus fail the eSCO setup. Normally the link manager is responsible for the negotiation of the parameters and actually fallback to SCO if no agreement can be reached. In cases where the link manager is just too stupid, then at least try to establish a SCO link if eSCO fails. For the Bluetooth devices with EDR support this includes handling packet types of EDR basebands. This is particular tricky since for the EDR the logic of enabling/disabling one specific packet type is turned around. This fix contains an extra bitmask to disable eSCO EDR packet when trying to fallback to a SCO connection. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add enhanced security model for Simple PairingMarcel Holtmann2009-02-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current security model is based around the flags AUTH, ENCRYPT and SECURE. Starting with support for the Bluetooth 2.1 specification this is no longer sufficient. The different security levels are now defined as SDP, LOW, MEDIUM and SECURE. Previously it was possible to set each security independently, but this actually doesn't make a lot of sense. For Bluetooth the encryption depends on a previous successful authentication. Also you can only update your existing link key if you successfully created at least one before. And of course the update of link keys without having proper encryption in place is a security issue. The new security levels from the Bluetooth 2.1 specification are now used internally. All old settings are mapped to the new values and this way it ensures that old applications still work. The only limitation is that it is no longer possible to set authentication without also enabling encryption. No application should have done this anyway since this is actually a security issue. Without encryption the integrity of the authentication can't be guaranteed. As default for a new L2CAP or RFCOMM connection, the LOW security level is used. The only exception here are the service discovery sessions on PSM 1 where SDP level is used. To have similar security strength as with a Bluetooth 2.0 and before combination key, the MEDIUM level should be used. This is according to the Bluetooth specification. The MEDIUM level will not require any kind of man-in-the-middle (MITM) protection. Only the HIGH security level will require this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix SCO state handling for incoming connectionsMarcel Holtmann2009-02-27
| | | | | | | | | | | | When the remote device supports only SCO connections, on receipt of the HCI_EV_CONN_COMPLETE event packet, the connect state is changed to BT_CONNECTED, but the socket state is not updated. Hence, the connect() call times out even though the SCO connection has been successfully established. Based on a report by Jaikumar Ganesh <jaikumar@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Enable per-module dynamic debug messagesMarcel Holtmann2008-11-30
| | | | | | | | | | | With the introduction of CONFIG_DYNAMIC_PRINTK_DEBUG it is possible to allow debugging without having to recompile the kernel. This patch turns all BT_DBG() calls into pr_debug() to support dynamic debug messages. As a side effect all CONFIG_BT_*_DEBUG statements are now removed and some broken debug entries have been fixed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Fix reference counting during ACL config stageMarcel Holtmann2008-09-09
| | | | | | | | | | | | The ACL config stage keeps holding a reference count on incoming connections when requesting the extended features. This results in keeping an ACL link up without any users. The problem here is that the Bluetooth specification doesn't define an ownership of the ACL link and thus it can happen that the implementation on the initiator side doesn't care about disconnecting unused links. In this case the acceptor needs to take care of this. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Use a more unique bus name for connectionsMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | When attaching Bluetooth low-level connections to the bus, the bus name is constructed from the remote address since at that time the connection handle is not assigned yet. This has worked so far, but also caused a lot of troubles. It is better to postpone the creation of the sysfs entry to the time when the connection actually has been established and then use its connection handle as unique identifier. This also fixes the case where two different adapters try to connect to the same remote device. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Initiate authentication during connection establishmentMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | | With Bluetooth 2.1 and Simple Pairing the requirement is that any new connection needs to be authenticated and that encryption has been switched on before allowing L2CAP to use it. So make sure that all the requirements are fulfilled and otherwise drop the connection with a minimal disconnect timeout of 10 milliseconds. This change only affects Bluetooth 2.1 devices and Simple Pairing needs to be enabled locally and in the remote host stack. The previous changes made sure that these information are discovered before any kind of authentication and encryption is triggered. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Use ACL config stage to retrieve remote featuresMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | | | | | | The Bluetooth technology introduces new features on a regular basis and for some of them it is important that the hardware on both sides support them. For features like Simple Pairing it is important that the host stacks on both sides have switched this feature on. To make valid decisions, a config stage during ACL link establishment has been introduced that retrieves remote features and if needed also the remote extended features (known as remote host features) before signalling this link as connected. This change introduces full reference counting of incoming and outgoing ACL links and the Bluetooth core will disconnect both if no owner of it is present. To better handle interoperability during the pairing phase the disconnect timeout for incoming connections has been increased to 10 seconds. This is five times more than for outgoing connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Track status of remote Simple Pairing modeMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | | | | | | The Simple Pairing process can only be used if both sides have the support enabled in the host stack. The current Bluetooth specification has three ways to detect this support. If an Extended Inquiry Result has been sent during inquiry then it is safe to assume that Simple Pairing is enabled. It is not allowed to enable Extended Inquiry without Simple Pairing. During the remote name request phase a notification with the remote host supported features will be sent to indicate Simple Pairing support. Also the second page of the remote extended features can indicate support for Simple Pairing. For all three cases the value of remote Simple Pairing mode is stored in the inquiry cache for later use. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Track status of Simple Pairing modeMarcel Holtmann2008-07-14
| | | | | | | | | | | The Simple Pairing feature is optional and needs to be enabled by the host stack first. The Linux kernel relies on the Bluetooth daemon to either enable or disable it, but at any time it needs to know the current state of the Simple Pairing mode. So track any changes made by external entities and store the current mode in the HCI device structure. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Disable disconnect timer during Simple PairingMarcel Holtmann2008-07-14
| | | | | | | | | During the Simple Pairing process the HCI disconnect timer must be disabled. The way to do this is by holding a reference count of the HCI connection. The Simple Pairing process on both sides starts with an IO Capabilities Request and ends with Simple Pairing Complete. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Update class of device value whenever possibleMarcel Holtmann2008-07-14
| | | | | | | | | | The class of device value can only be retrieved via inquiry or during an incoming connection request. Outgoing connections can't ask for the class of device. To compensate for this the value is stored and copied via the inquiry cache, but currently only updated via inquiry. This update should also happen during an incoming connection request. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Some cleanups for HCI event handlingMarcel Holtmann2008-07-14
| | | | | | | Some minor cosmetic cleanups to the HCI event handling to make the code easier to read and understand. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Make use of the default link policy settingsMarcel Holtmann2008-07-14
| | | | | | | | | | The Bluetooth specification supports the default link policy settings on a per host controller basis. For every new connection the link manager would then use these settings. It is better to use this instead of bothering the controller on every connection setup to overwrite the default settings. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Track connection packet type changesMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | | | | | | | The connection packet type can be changed after the connection has been established and thus needs to be properly tracked to ensure that the host stack has always correct and valid information about it. On incoming connections the Bluetooth core switches the supported packet types to the configured list for this controller. However the usefulness of this feature has been questioned a lot. The general consent is that every Bluetooth host stack should enable as many packet types as the hardware actually supports and leave the decision to the link manager software running on the Bluetooth chip. When running on Bluetooth 2.0 or later hardware, don't change the packet type for incoming connections anymore. This hardware likely supports Enhanced Data Rate and thus leave it completely up to the link manager to pick the best packet type. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Support the case when headset falls back to SCO linkMarcel Holtmann2008-07-14
| | | | | | | | | | When trying to establish an eSCO link between two devices then it can happen that the remote device falls back to a SCO link. Currently this case is not handled correctly and the message dispatching will break since it is looking for eSCO packets. So in case the configured link falls back to SCO overwrite the link type with the correct value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Update authentication status after successful encryptionMarcel Holtmann2008-07-14
| | | | | | | | | | | | | | | | | The authentication status is not communicated to both parties. This is actually a flaw in the Bluetooth specification. Only the requesting side really knows if the authentication was successful or not. This piece of information is however needed on the other side to know if it has to trigger the authentication procedure or not. Worst case is that both sides will request authentication at different times, but this should be avoided since it costs extra time when setting up a new connection. For Bluetooth encryption it is required to authenticate the link first and the encryption status is communicated to both sides. So when a link is switched to encryption it is possible to update the authentication status since it implies an authenticated link. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* bluetooth: use get/put_unaligned_* helpersHarvey Harrison2008-05-02
| | | | | | Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Add support for handling simple eSCO linksMarcel Holtmann2007-10-22
| | | | | | | | | | With the Bluetooth 1.2 specification the Extended SCO feature for better audio connections was introduced. So far the Bluetooth core wasn't able to handle any eSCO connections correctly. This patch adds simple eSCO support while keeping backward compatibility with older devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Switch from OGF+OCF to using only opcodesMarcel Holtmann2007-10-22
| | | | | | | | | | | | The Bluetooth HCI commands are divided into logical OGF groups for easier identification of their purposes. While this still makes sense for the written specification, its makes the code only more complex and harder to read. So instead of using separate OGF and OCF values to identify the commands, use a common 16-bit opcode that combines both values. As a side effect this also reduces the complexity of OGF and OCF calculations during command header parsing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Add basics to better support and handle eSCO linksMarcel Holtmann2007-07-11
| | | | | | | | To better support and handle eSCO links in the future a bunch of constants needs to be added and some basic routines need to be updated. This is the initial step. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [NET] BLUETOOTH: Use cpu_to_le{16,32}() where appropriate.YOSHIFUJI Hideaki2007-04-26
| | | | | Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] remove many unneeded #includes of sched.hTim Schmielau2007-02-14
| | | | | | | | | | | | | | | | | | | | | | | | After Al Viro (finally) succeeded in removing the sched.h #include in module.h recently, it makes sense again to remove other superfluous sched.h includes. There are quite a lot of files which include it but don't actually need anything defined in there. Presumably these includes were once needed for macros that used to live in sched.h, but moved to other header files in the course of cleaning it up. To ease the pain, this time I did not fiddle with any header files and only removed #includes from .c-files, which tend to cause less trouble. Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha, arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig, allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all configs in arch/arm/configs on arm. I also checked that no new warnings were introduced by the patch (actually, some warnings are removed that were emitted by unnecessarily included header files). Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [NET] BLUETOOTH: Fix whitespace errors.YOSHIFUJI Hideaki2007-02-11
| | | | | Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Handling pending connect attempts after inquiryMarcel Holtmann2006-11-21
| | | | | | | After an inquiry completed or got canceled the Bluetooth core should check for any pending connect attempts. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Support concurrent connect requestsMarcel Holtmann2006-10-16
| | | | | | | | | | | Most Bluetooth chips don't support concurrent connect requests, because this would involve a multiple baseband page with only one radio. In the case an upper layer like L2CAP requests a concurrent connect these chips return the error "Command Disallowed" for the second request. If this happens it the responsibility of the Bluetooth core to queue the request and try again after the previous connect attempt has been completed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth]: Don't update disconnect timer for incoming connectionsMarcel Holtmann2006-09-28
| | | | | | | | | | | | In the case of device pairing the only safe method is to establish a low-level ACL link. In this case, the remote side should not use the disconnect timer to give the other side the chance to enter the PIN code. If the disconnect timer is used, the connection will be dropped to soon, because it is impossible to identify an actual user of this link. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Support create connection cancel commandMarcel Holtmann2006-09-28
| | | | | | | | | | | | In case of non-blocking connects it is possible that the last user of an ACL link quits before the connection has been fully established. This will lead to a race condition where the internal state of a connection is closed, but the actual link has been established and is active. In case of Bluetooth 1.2 and later devices it is possible to call create connection cancel to abort the connect. For older devices the disconnect timer will be used to trigger the needed disconnect. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Read local version information on device initMarcel Holtmann2006-09-28
| | | | | | | | The local version information are needed to identify certain feature sets of devices. They must be read on device init and stored for later use. It is also possible to access them through the device model. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Handle command complete event for exit periodic inquiryMarcel Holtmann2006-09-28
| | | | | | | The command complete event of the exit periodic inquiry command must clear the HCI_INQUIRY flag and finish the HCI request. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Add automatic sniff mode supportMarcel Holtmann2006-07-03
| | | | | | | | This patch introduces the automatic sniff mode feature. This allows the host to switch idle connections into sniff mode to safe power. Signed-off-by: Ulisses Furquim <ulissesf@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* [Bluetooth] Correct SCO buffer size on requestMarcel Holtmann2006-07-03
| | | | | | | | This patch introduces a quirk that allows the drivers to tell the host to correct the SCO buffer size values. Signed-off-by: Olivier Galibert <galibert@pobox.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-30
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [Bluetooth]: Add endian annotations to the coreMarcel Holtmann2005-11-08
| | | | | | | This patch adds the endian annotations to the Bluetooth core. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* [Bluetooth] Add support for extended inquiry responsesMarcel Holtmann2005-09-12
| | | | | | | This patch adds the handling of the extended inquiry responses and inserts them into the inquiry cache. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-13 12:26:55 -0500