linux-toradex.git/net/bluetooth/hci_core.c, branch v4.10

Bluetooth: Fix wrong New Settings event when closing HCI User Channel

2016-09-19T18:19:34+00:00

When closing HCI User Channel, the New Settings event was send out to
inform about changed settings. However such event is wrong since the
exclusive HCI User Channel access is active until the Index Added event
has been sent.

@ USER Close: test
@ MGMT Event: New Settings (0x0006) plen 4
        Current settings: 0x00000ad0
          Bondable
          Secure Simple Pairing
          BR/EDR
          Low Energy
          Secure Connections
= Close Index: 00:14:EF:22:04:12
@ MGMT Event: Index Added (0x0004) plen 0

Calling __mgmt_power_off from hci_dev_do_close requires an extra check
for an active HCI User Channel.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Add debugfs fields for hardware and firmware info

2016-07-18T06:33:28+00:00

Some Bluetooth controllers allow for reading hardware and firmware
related vendor specific infos. If they are available, then they can be
exposed via debugfs now.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Rename HCI_BREDR into HCI_PRIMARY

2016-07-09T18:37:13+00:00

The HCI_BREDR naming is confusing since it actually stands for Primary
Bluetooth Controller. Which is a term that has been used in the latest
standard. However from a legacy point of view there only really have
been Basic Rate (BR) and Enhanced Data Rate (EDR). Recent versions of
Bluetooth introduced Low Energy (LE) and made this terminology a little
bit confused since Dual Mode Controllers include BR/EDR and LE. To
simplify this the name HCI_PRIMARY stands for the Primary Controller
which can be a single mode or dual mode controller.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: fix power_on vs close race

2016-05-13T14:50:23+00:00

With all the latest fixes applied, I am still able to reproduce this
(and other) warning(s):
WARNING: CPU: 1 PID: 19684 at ../kernel/workqueue.c:4092 destroy_workqueue+0x70a/0x770()
...
Call Trace:
 [] ? dump_stack+0xb3/0x112
 [] ? warn_slowpath_common+0xde/0x140
 [] ? destroy_workqueue+0x70a/0x770
 [] ? warn_slowpath_null+0x2e/0x40
 [] ? destroy_workqueue+0x70a/0x770
 [] ? hci_unregister_dev+0x2a9/0x720 [bluetooth]
 [] ? vhci_release+0x7b/0xf0 [hci_vhci]
 [] ? vhci_flush+0x50/0x50 [hci_vhci]
 [] ? do_exit+0x863/0x2b90

This is due to race present in the hci_unregister_dev path.
hdev->power_on work races with hci_dev_do_close. One tries to open,
the other tries to close, leading to warning like the above. (Another
example is a warning in kobject_get or kobject_put depending on who
wins the race.)

Fix this by switching those two racers to ensure hdev->power_on never
triggers while hci_dev_do_close is in progress.

Signed-off-by: Jiri Slaby 
Signed-off-by: Marcel Holtmann

Bluetooth: hci_core: cancel power off delayed work properly

2016-02-23T19:29:38+00:00

When the HCI_AUTO_OFF flag is cleared, the power_off delayed work need
to be cancel or HCI will be powered off even if it's managed.

Signed-off-by: Wei-Ning Huang 
Signed-off-by: Marcel Holtmann

Bluetooth: Use managed version of led_trigger_register in LED trigger

2016-02-23T19:29:36+00:00

Recently a managed version of led_trigger_register was introduced.
Using devm_led_trigger_register allows to simplify the LED trigger code.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Marcel Holtmann

Bluetooth: add LED trigger for indicating HCI is powered up

2016-02-23T19:29:35+00:00

Add support for LED triggers to the Bluetooth subsystem and add kernel
config symbol BT_LEDS for it.

For now one trigger for indicating "HCI is powered up" is supported.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Marcel Holtmann

Bluetooth: hci_core: Avoid mixing up req_complete and req_complete_skb

2016-02-20T07:52:28+00:00

In commit 44d271377479 ("Bluetooth: Compress the size of struct
hci_ctrl") we squashed down the size of the structure by using a union
with the assumption that all users would use the flag to determine
whether we had a req_complete or a req_complete_skb.

Unfortunately we had a case in hci_req_cmd_complete() where we weren't
looking at the flag.  This can result in a situation where we might be
storing a hci_req_complete_skb_t in a hci_req_complete_t variable, or
vice versa.

During some testing I found at least one case where the function
hci_req_sync_complete() was called improperly because the kernel thought
that it didn't require an SKB.  Looking through the stack in kgdb I
found that it was called by hci_event_packet() and that
hci_event_packet() had both of its locals "req_complete" and
"req_complete_skb" pointing to the same place: both to
hci_req_sync_complete().

Let's make sure we always check the flag.

For more details on debugging done, see .

Fixes: 44d271377479 ("Bluetooth: Compress the size of struct hci_ctrl")
Signed-off-by: Douglas Anderson 
Acked-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: use list_for_each_entry*

2015-12-20T07:11:10+00:00

Use list_for_each_entry*() instead of list_for_each*() to simplify
the code.

Signed-off-by: Geliang Tang 
Signed-off-by: Marcel Holtmann

Bluetooth: Clean up current advertising instance tracking

2015-12-09T23:51:50+00:00

We can simplify a lot of code by making sure hdev->cur_adv_instance is
always up-to-date. This allows e.g. the removal of the
get_current_adv_instance() helper function and the special
HCI_ADV_CURRENT value. This patch also makes selecting instance 0x00
explicit in the various calls where advertising instances aren't
enabled, e.g. when HCI_ADVERTISING is set or we've just finished
enabling LE.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann