* Re: shutdown(3) and bluetooth.
From: Marcel Holtmann @ 2013-11-12 22:32 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, linux-bluetooth@vger.kernel.org development
In-Reply-To: <20131112221038.GA6689@redhat.com>
Hi Dave,
>>> Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
>>> and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
>>>
>>> Is there something I should be doing to guarantee that this operation
>>> will either time out, or return instantly ?
>>>
>>> In this specific case, I doubt anything is on the "sender" end of the socket, so
>>> it's going to be waiting forever for a state change that won't arrive.
>>
>> can you give us some extra information here. What kind of Bluetooth socket is this actually. From the top of my head, I have no idea why we would even wait forever. Normally when all low-level links are gone, the socket will shut down anyway.
>
> Here's the info I found in the logs, it looks like this was the only bluetooth socket.
>
> fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2
> Setsockopt(1 d 2134000 8) on fd 195
this is a bit confusing. Protocol 2 is actually SCO, but the stack trace shows RFCOMM.
> it doesn't look like any further operations were done on this fd during the fuzzers runtime.
>
> Quick way to reproduce:
>
> ./trinity -P PF_BLUETOOTH -l off -c setsockopt
>
> let it run a few seconds, and then ctrl-c. The main process will never exit.
>
> 5814 pts/6 Ss 0:00 | \_ bash
> 5876 pts/6 S+ 0:00 | | \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt
> 5877 pts/6 Z+ 0:00 | | \_ [trinity] <defunct>
> 5878 pts/6 S+ 0:01 | | \_ [trinity-main]
>
> $ sudo cat /proc/5878/stack
> [<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth]
> [<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm]
> [<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm]
> [<ffffffff81532fcf>] sock_release+0x1f/0x80
> [<ffffffff81533042>] sock_close+0x12/0x20
> [<ffffffff811a9ac1>] __fput+0xe1/0x230
> [<ffffffff811a9c5e>] ____fput+0xe/0x10
> [<ffffffff8108534c>] task_work_run+0xbc/0xe0
> [<ffffffff8106944c>] do_exit+0x2bc/0xa20
> [<ffffffff81069c2f>] do_group_exit+0x3f/0xa0
> [<ffffffff81069ca4>] SyS_exit_group+0x14/0x20
> [<ffffffff81656b27>] tracesys+0xdd/0xe2
> [<ffffffffffffffff>] 0xffffffffffffffff
What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly. There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock.
Regards
Marcel
^ permalink raw reply
* Re: shutdown(3) and bluetooth.
From: Dave Jones @ 2013-11-12 22:10 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev, linux-bluetooth@vger.kernel.org development
In-Reply-To: <DF4C2B40-BD87-4E88-911D-E3E5F488CAE4@holtmann.org>
On Wed, Nov 13, 2013 at 06:56:23AM +0900, Marcel Holtmann wrote:
> Hi Dave,
>
> > Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
> > and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
> >
> > Is there something I should be doing to guarantee that this operation
> > will either time out, or return instantly ?
> >
> > In this specific case, I doubt anything is on the "sender" end of the socket, so
> > it's going to be waiting forever for a state change that won't arrive.
>
> can you give us some extra information here. What kind of Bluetooth socket is this actually. From the top of my head, I have no idea why we would even wait forever. Normally when all low-level links are gone, the socket will shut down anyway.
Here's the info I found in the logs, it looks like this was the only bluetooth socket.
fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2
Setsockopt(1 d 2134000 8) on fd 195
it doesn't look like any further operations were done on this fd during the fuzzers runtime.
Quick way to reproduce:
./trinity -P PF_BLUETOOTH -l off -c setsockopt
let it run a few seconds, and then ctrl-c. The main process will never exit.
5814 pts/6 Ss 0:00 | \_ bash
5876 pts/6 S+ 0:00 | | \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt
5877 pts/6 Z+ 0:00 | | \_ [trinity] <defunct>
5878 pts/6 S+ 0:01 | | \_ [trinity-main]
$ sudo cat /proc/5878/stack
[<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth]
[<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm]
[<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm]
[<ffffffff81532fcf>] sock_release+0x1f/0x80
[<ffffffff81533042>] sock_close+0x12/0x20
[<ffffffff811a9ac1>] __fput+0xe1/0x230
[<ffffffff811a9c5e>] ____fput+0xe/0x10
[<ffffffff8108534c>] task_work_run+0xbc/0xe0
[<ffffffff8106944c>] do_exit+0x2bc/0xa20
[<ffffffff81069c2f>] do_group_exit+0x3f/0xa0
[<ffffffff81069ca4>] SyS_exit_group+0x14/0x20
[<ffffffff81656b27>] tracesys+0xdd/0xe2
[<ffffffffffffffff>] 0xffffffffffffffff
Dave
^ permalink raw reply
* Re: shutdown(3) and bluetooth.
From: Marcel Holtmann @ 2013-11-12 21:56 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, linux-bluetooth@vger.kernel.org development
In-Reply-To: <20131112211125.GA2912@redhat.com>
Hi Dave,
> Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
> and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
>
> Is there something I should be doing to guarantee that this operation
> will either time out, or return instantly ?
>
> In this specific case, I doubt anything is on the "sender" end of the socket, so
> it's going to be waiting forever for a state change that won't arrive.
can you give us some extra information here. What kind of Bluetooth socket is this actually. From the top of my head, I have no idea why we would even wait forever. Normally when all low-level links are gone, the socket will shut down anyway.
Regards
Marcel
^ permalink raw reply
* [PATCH] Enable autosuspend for Intel Bluetooth device
From: Tedd Ho-Jeong An @ 2013-11-12 21:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: don.fry, marcel, tedd.an
From: Tedd Ho-Jeong An <tedd.an@intel.com>
This patch enables autosuspend for Intel Bluetooth device.
After btusb is loaded for Intel Bluetooth device, the power/control
attribute contains "on" value by default which disables the autosuspend.
Based on the USB PM document(Documentation/usb/power-management.txt),
kernel disabled the autosuspend for all devices other than hub by default.
"The USB specification states that all USB devices must support power
management. Nevertheless, the sad fact is that many devices do not
support it very well. You can suspend them all right, but when you
try to resume them they disconnect themselves from the USB bus or
they stop working entirely. This seems to be especially prevalent
among printers and scanners, but plenty of other types of device have
the same deficiency.
For this reason, by default the kernel disables autosuspend (the
power/control attribute is initialized to "on") for all devices other
than hubs. Hubs, at least, appear to be reasonably well-behaved in
this regard."
This document also described how the driver can enables the autosuspend
by using an USB api.
"Drivers can enable autosuspend for their devices by calling
usb_enable_autosuspend(struct usb_device *udev);
in their probe() routine, if they know that the device is capable of
suspending and resuming correctly. This is exactly equivalent to
writing "auto" to the device's power/control attribute."
For Intel Bluetooth device, the autosuspend needs to be enabled so the
device can transit to LPM(Low Power Mode) and ULPM(Ultra LPM) states after
receiving suspend message from the host.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
---
drivers/bluetooth/btusb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c206091..0dc9409 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1437,8 +1437,10 @@ static int btusb_probe(struct usb_interface *intf,
if (id->driver_info & BTUSB_BCM92035)
hdev->setup = btusb_setup_bcm92035;
- if (id->driver_info & BTUSB_INTEL)
+ if (id->driver_info & BTUSB_INTEL) {
+ usb_enable_autosuspend(data->udev);
hdev->setup = btusb_setup_intel;
+ }
/* Interface numbers are hardcoded in the specification */
data->isoc = usb_ifnum_to_if(data->udev, 1);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Enable autosuspend for Intel Bluetooth device
From: Tedd Ho-Jeong An @ 2013-11-12 21:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: don.fry
From: Tedd Ho-Jeong An <tedd.an@intel.com>
This patch enables autosuspend for Intel Bluetooth device.
After btusb is loaded for Intel Bluetooth device, the power/control
attribute contains "on" value by default which disables the autosuspend.
Based on the USB PM document(Documentation/usb/power-management.txt),
kernel disabled the autosuspend for all devices other than hub by default.
"The USB specification states that all USB devices must support power
management. Nevertheless, the sad fact is that many devices do not
support it very well. You can suspend them all right, but when you
try to resume them they disconnect themselves from the USB bus or
they stop working entirely. This seems to be especially prevalent
among printers and scanners, but plenty of other types of device have
the same deficiency.
For this reason, by default the kernel disables autosuspend (the
power/control attribute is initialized to "on") for all devices other
than hubs. Hubs, at least, appear to be reasonably well-behaved in
this regard."
This document also described how the driver can enables the autosuspend
by using an USB api.
"Drivers can enable autosuspend for their devices by calling
usb_enable_autosuspend(struct usb_device *udev);
in their probe() routine, if they know that the device is capable of
suspending and resuming correctly. This is exactly equivalent to
writing "auto" to the device's power/control attribute."
For Intel Bluetooth device, the autosuspend needs to be enabled so the
device can transit to LPM(Low Power Mode) and ULPM(Ultra LPM) states after
receiving suspend message from the host.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
---
drivers/bluetooth/btusb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c206091..0dc9409 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -1437,8 +1437,10 @@ static int btusb_probe(struct usb_interface *intf,
if (id->driver_info & BTUSB_BCM92035)
hdev->setup = btusb_setup_bcm92035;
- if (id->driver_info & BTUSB_INTEL)
+ if (id->driver_info & BTUSB_INTEL) {
+ usb_enable_autosuspend(data->udev);
hdev->setup = btusb_setup_intel;
+ }
/* Interface numbers are hardcoded in the specification */
data->isoc = usb_ifnum_to_if(data->udev, 1);
--
1.7.9.5
^ permalink raw reply related
* Re: shutdown(3) and bluetooth.
From: David Miller @ 2013-11-12 21:13 UTC (permalink / raw)
To: davej; +Cc: netdev, linux-bluetooth, linux-wireless
In-Reply-To: <20131112211125.GA2912@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Tue, 12 Nov 2013 16:11:25 -0500
> Is shutdown() allowed to block indefinitely ? The man page doesn't say either way,
> and I've noticed that my fuzz tester occasionally hangs for days spinning in bt_sock_wait_state()
>
> Is there something I should be doing to guarantee that this operation
> will either time out, or return instantly ?
>
> In this specific case, I doubt anything is on the "sender" end of the socket, so
> it's going to be waiting forever for a state change that won't arrive.
Adding bluetooth and wireless lists. Dave, please consult MAINTAINERS when
asking questions like this, thanks!
^ permalink raw reply
* [PATCH] Bluetooth: Add support for Intel Bluetooth device [8087:0a2a]
From: Tedd Ho-Jeong An @ 2013-11-12 21:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: don.fry, tedd.an, marcel
From: Tedd Ho-Jeong An <tedd.an@intel.com>
This patch adds support for new Intel Bluetooth device.
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=8087 ProdID=0a2a Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
---
drivers/bluetooth/btusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c206091..0263997 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -225,6 +225,7 @@ static const struct usb_device_id blacklist_table[] = {
/* Intel Bluetooth device */
{ USB_DEVICE(0x8087, 0x07dc), .driver_info = BTUSB_INTEL },
+ { USB_DEVICE(0x8087, 0x0a2a), .driver_info = BTUSB_INTEL },
{ } /* Terminating entry */
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH_v2 3/4] android/pan: Add notify method to PAN notifications
From: Ravi kumar Veeramally @ 2013-11-12 19:33 UTC (permalink / raw)
To: linux-bluetooth, johan.hedberg
In-Reply-To: <20131112170623.GA5058@x220.p-661hnu-f1>
Hi Johan,
On 12.11.2013 19:06, Johan Hedberg wrote:
> Hi Ravi,
>
> On Tue, Nov 12, 2013, Ravi kumar Veeramally wrote:
>> ---
>> android/hal-pan.c | 6 ++++++
>> android/hal.h | 1 +
>> 2 files changed, 7 insertions(+)
> I've applied the first two patches, but there's one issue with this one:
>
>> +void bt_notify_pan(uint16_t opcode, void *buf, uint16_t len)
>> +{
>> + if (!interface_ready())
>> + return;
>> +}
> Why is opcode uint16_t instead of uint8_t? Haven't we defined it as
> uint8_t in our IPC document?
>
There are few other places like adapter and hid it is declared as uint16_t.
I will fix that too and send you v3 of these two.
Thanks,
Ravi.
^ permalink raw reply
* Re: [RFC BlueZ v1] doc: Add GATT API
From: Claudio Takahasi @ 2013-11-12 18:49 UTC (permalink / raw)
To: Scott James Remnant; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CAHZ1yCmTdG_ynyfXj0CYhRsPWdM5MBeySvG1Wd5Xb+nEvCVH0A@mail.gmail.com>
Hi Scott,
On Mon, Nov 11, 2013 at 3:56 PM, Scott James Remnant <keybuk@google.com> wrote:
> On Tue, Oct 15, 2013 at 11:39 AM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>
>> +GATT local and remote services share the same high-level D-Bus API. Local
>> +refers to local GATT based service exported by a BlueZ plugin or an external
>> +application. Remote refers to GATT services exported by the peer.
>
> If this object format also be used to describe the services and
> characteristics of a remote device, how will those be handled? I
> assume that we don't want to get the value of every single
> characteristic on connection - that seems wasteful, and would quite
> rapidly drain the batteries of smaller devices.
Declarations are stored/cached. All attributes are discovered only
once in the first connection or after bonding.
When re-connecting, value is read on demand when the user calls
Properties Get (if value is not cached).
Another point is: Notification or Indication are automatically enabled
after the discovery procedure.
>
>
> How will service changed be handled? How will BlueZ track the set of
> applications, and the set of services etc. defined by those
> applications in a manner that keeps handles consistent? How will it
> handle generating the Services Changed notification in the cases where
> the set of applications and/or services change, or the handles change?
We implemented a hash of declarations. Using the "Id" provided in the
options dictionary (see RegisterAgent) we are able to identity if the
external service changed its attributes.
However, I don' t think we will upstream this approach soon, Marcel
wants a simpler approach: always send ServiceChanged.
If you want to understand more details of the implementation see:
https://db.tt/FkWob6jw
>
>
>> +Characteristic hierarchy
>> +========================
> :
>> +Service org.bluez
>> +Interface org.bluez.Characteristic1 [Experimental]
>> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX/charYYYY
>
> This would also need a "Permissions" property akin to the one you have
> for Descriptors - characteristics can be "not accessible", read-only,
> write-only, read/write - and can also require authorization,
> authentication, encryption and minimum encryption key sizes - as with
> descriptors.
It is implemented already, there is an optional "Flags" property :
"array{string} Flags [read-only, optional]"
But this is not enough, there are some cases that the permissions are
defined by the external application.
>
>> + array{byte} Value [read-write]
>> +
>> + Cached Value of the characteristic. If present, the
>> + value will be cached by bluetoothd and updated when the
>> + PropertiesChanged signal is emitted.
>> +
>> + External services must emit this signal when the
>> + characteristic supports notification/indication, so
>> + that clients can be notified of the new value.
>
> The PropertiesChanged signal explains how Notification will be handled
> - but how will Indication? How will a service receive the Indication
> Confirmation from the remote devices?
The bluetoothd core manages the Confirmation. In my opinion clients
listening for PropertiesChanged don' t need to know the difference
between notification and indication.
Allow an external client to manage the Confirmation will insert
additional complexity without giving real benefits.
>
>
>> +Application Manager hierarchy
>> +=============================
> :
>> +Service org.bluez
>> +Interface org.bluez.ApplicationManager1 [Experimental]
>> +Object path /org/bluez
>> +
>> +Methods RegisterAgent(object application, dict options)
>
> Shouldn't this be "RegisterApplication" ?
>
> I assume that the object path is the one to which D-Bus Object Manager
> queries are sent, allowing a single process to implement multiple
> "applications"?
The name is still open, but remember that this method might be used to
register client and servers.
At the moment "object path" together with DBus BUS id are used for
identification only. Multiple GATT services can be registered
independently of the application object path.
Application object path can be used to manage *groups* of services
exposed by the single process.
>
>> + UnregisterAgent(object application)
>
> Likewise, "UnregisterApplication" ?
>
>> +Application Agent hierarchy
>> +===========================
>> +
>> +Service unique name
>> +Interface org.bluez.ApplicationAgent1 [Experimental]
>> +Object path freely definable
>> +
>
> "Agent" seems unnnecessary here - if the object is an Application,
> then org.bluez.Application1 would be a decent enough name. Thus an
> "Application" consists of multiple Services, each of which consists of
> multiple Characteristics, each of which has multiple Descriptors
IMO "Agent" gives a better association with its functionality, it
reminds me org.bluez.Agent1.
Let's wait the opinion of the others developers...
Regards,
Claudio
^ permalink raw reply
* Re: [PATCH_v2 3/4] android/pan: Add notify method to PAN notifications
From: Johan Hedberg @ 2013-11-12 17:06 UTC (permalink / raw)
To: Ravi kumar Veeramally; +Cc: linux-bluetooth
In-Reply-To: <1384266042-6344-4-git-send-email-ravikumar.veeramally@linux.intel.com>
Hi Ravi,
On Tue, Nov 12, 2013, Ravi kumar Veeramally wrote:
> ---
> android/hal-pan.c | 6 ++++++
> android/hal.h | 1 +
> 2 files changed, 7 insertions(+)
I've applied the first two patches, but there's one issue with this one:
> +void bt_notify_pan(uint16_t opcode, void *buf, uint16_t len)
> +{
> + if (!interface_ready())
> + return;
> +}
Why is opcode uint16_t instead of uint8_t? Haven't we defined it as
uint8_t in our IPC document?
Johan
^ permalink raw reply
* Re: [PATCH v3 0/5] Add support for registering local SDP records
From: Johan Hedberg @ 2013-11-12 17:00 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Tue, Nov 12, 2013, Szymon Janc wrote:
> v3:
> - fixed Johan comments
>
> V2:
> - don't use bt_uuid_t
> - few bugfixes
>
> V1 cover:
> This adds support for manipulating local SDP database with
> bt_adapter_add_record and bt_adapter_remove_record functions. Those should
> be called when HAL service is registered or unregistered.
>
> This also adds DeviceID record as at least 1 local UUID is needed by Android to
> properly handle remote device profiles.
>
> Last but not least: With this serie it is possible to connect HID device from
> Android UI (Settings application). \O/
>
> --
> BR
> Szymon Janc
>
> Marcin Kraglak (3):
> android: Add and remove sdp records and uuids
> android: Clear adapter uuids during initialization
> android: Add support for getting UUIDs property
>
> Szymon Janc (2):
> android: Remove not needed include
> android: Register DeviceID record when adapter is initialized
>
> android/adapter.c | 202 ++++++++++++++++++++++++++++++++++++++++++++++++++----
> android/adapter.h | 3 +
> 2 files changed, 192 insertions(+), 13 deletions(-)
All five patches have been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/3] android/hidhost: Remove deprecated idle opcode from ipc document
From: Marcel Holtmann @ 2013-11-12 15:57 UTC (permalink / raw)
To: Ravi Kumar Veeramally; +Cc: linux-bluetooth@vger.kernel.org development
In-Reply-To: <5281F502.9080506@linux.intel.com>
Hi Ravi,
>>> Idle time is deprecated in HID 1_1. So remove it from ipc document
>>> and update GET_REPORT and VIRTUAL_UNPLUG opcode values.
>>> ---
>>> android/hal-ipc-api.txt | 10 ++--------
>>> android/hal-msg.h | 4 ++--
>>> 2 files changed, 4 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
>>> index 91ea280..57f4c13 100644
>>> --- a/android/hal-ipc-api.txt
>>> +++ b/android/hal-ipc-api.txt
>>> @@ -614,20 +614,14 @@ Notifications:
>>> 0x01 = Boot
>>> 0xff = Unsupported
>>>
>>> - Opcode 0x84 - Idle Time notification
>>> -
>>> - Notification parameters: Remote address (6 octets)
>>> - Status (1 octet)
>>> - Idle time (2 octets)
>> so what does HID_1.1 actually mean? I still see this notification in bt_hh.h.
>>
>> Regards
>>
>> Marcel
>>
> In HID_SPEC_V11 (3.1) Get Idle and Set Idle are deprecated. And even in bt_hh.h
> get_idle and set_idle interfaces are not available. Bluedroid had implementation
> of those two in bluedroid/btif/src/btif_hh.c but in interface struct those are commented out.
> I didn't find the call back call there. That's why I updated ipc-doc.
if they are not using this notification in the Bluetooth service, then we do not need to implemented.
Regards
Marcel
^ permalink raw reply
* [PATCH v3 5/5] android: Register DeviceID record when adapter is initialized
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
Register DeviceID SDP record and update local UUIDs after DeviceID
information is passed to kernel.
---
android/adapter.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/android/adapter.c b/android/adapter.c
index 2c95e54..2fd6aeb 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -46,6 +46,10 @@
#include "utils.h"
#include "adapter.h"
+#define DEVICE_ID_SOURCE 0x0002 /* USB */
+#define DEVICE_ID_VENDOR 0x1d6b /* Linux Foundation */
+#define DEVICE_ID_PRODUCT 0x0247 /* BlueZ for Android */
+
/* Default to DisplayYesNo */
#define DEFAULT_IO_CAPABILITY 0x01
/* Default discoverable timeout 120sec as in Android */
@@ -1197,20 +1201,28 @@ static void set_device_id(void)
{
struct mgmt_cp_set_device_id cp;
uint8_t major, minor;
+ uint16_t version;
if (sscanf(VERSION, "%hhu.%hhu", &major, &minor) != 2)
return;
+ version = major << 8 | minor;
+
memset(&cp, 0, sizeof(cp));
- cp.source = htobs(0x0002); /* USB */
- cp.vendor = htobs(0x1d6b); /* Linux Foundation */
- cp.product = htobs(0x0247); /* BlueZ for Android */
- cp.version = htobs(major << 8 | minor);
+ cp.source = htobs(DEVICE_ID_SOURCE);
+ cp.vendor = htobs(DEVICE_ID_VENDOR);
+ cp.product = htobs(DEVICE_ID_PRODUCT);
+ cp.version = htobs(version);
if (mgmt_send(adapter->mgmt, MGMT_OP_SET_DEVICE_ID,
adapter->index, sizeof(cp), &cp,
NULL, NULL, NULL) == 0)
error("Failed to set device id");
+
+ register_device_id(DEVICE_ID_SOURCE, DEVICE_ID_VENDOR,
+ DEVICE_ID_PRODUCT, version);
+
+ bt_adapter_add_record(sdp_record_find(0x10000), 0x00);
}
static void set_adapter_name_complete(uint8_t status, uint16_t length,
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 4/5] android: Add support for getting UUIDs property
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
From: Marcin Kraglak <marcin.kraglak@tieto.com>
This method will call adapter_properties_cb with uuids of
adapter. Method is called also when uuid is added or removed.
---
android/adapter.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/android/adapter.c b/android/adapter.c
index a42cdcb..2c95e54 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -998,6 +998,45 @@ static void uuid16_to_uint128(uint16_t uuid, uint128_t *u128)
ntoh128(&uuid128.value.uuid128, u128);
}
+static bool get_uuids(void)
+{
+ struct hal_ev_adapter_props_changed *ev;
+ GSList *list = adapter->uuids;
+ unsigned int uuid_count = g_slist_length(list);
+ int len = uuid_count * sizeof(uint128_t);
+ uint8_t buf[BASELEN_PROP_CHANGED + len];
+ uint8_t *p;
+ int i;
+
+ memset(buf, 0, sizeof(buf));
+ ev = (void *) buf;
+
+ ev->num_props = 1;
+ ev->status = HAL_STATUS_SUCCESS;
+
+ ev->props[0].type = HAL_PROP_ADAPTER_UUIDS;
+ ev->props[0].len = len;
+ p = ev->props->val;
+
+ for (; list; list = g_slist_next(list)) {
+ uint16_t uuid = GPOINTER_TO_UINT(list->data);
+ uint128_t uint128;
+
+ uuid16_to_uint128(uuid, &uint128);
+
+ /* Android expects swapped bytes in uuid */
+ for (i = 0; i < 16; i++)
+ p[15 - i] = uint128.data[i];
+
+ p += sizeof(uint128_t);
+ }
+
+ ipc_send(notification_sk, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_EV_ADAPTER_PROPS_CHANGED, sizeof(buf), ev, -1);
+
+ return true;
+}
+
static void remove_uuid_complete(uint8_t status, uint16_t length,
const void *param, void *user_data)
{
@@ -1008,6 +1047,10 @@ static void remove_uuid_complete(uint8_t status, uint16_t length,
}
mgmt_dev_class_changed_event(adapter->index, length, param, NULL);
+
+ /* send notification only if bluetooth service is registered */
+ if (notification_sk >= 0)
+ get_uuids();
}
static void remove_uuid(uint16_t uuid)
@@ -1033,6 +1076,10 @@ static void add_uuid_complete(uint8_t status, uint16_t length,
}
mgmt_dev_class_changed_event(adapter->index, length, param, NULL);
+
+ /* send notification only if bluetooth service is registered */
+ if (notification_sk >= 0)
+ get_uuids();
}
static void add_uuid(uint8_t svc_hint, uint16_t uuid)
@@ -1346,14 +1393,6 @@ static bool get_name(void)
return true;
}
-static bool get_uuids(void)
-{
- DBG("Not implemented");
-
- /* TODO: Add implementation */
-
- return false;
-}
static bool get_class(void)
{
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 3/5] android: Clear adapter uuids during initialization
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
From: Marcin Kraglak <marcin.kraglak@tieto.com>
Clear adapter uuids during init. We have to do it before
other profiles will be able to register sdp records and add
their uuids.
---
android/adapter.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/android/adapter.c b/android/adapter.c
index 92949f9..a42cdcb 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -1208,6 +1208,17 @@ static uint8_t set_discoverable_timeout(uint8_t *timeout)
return HAL_STATUS_SUCCESS;
}
+
+static void clear_uuids(void)
+{
+ struct mgmt_cp_remove_uuid cp;
+
+ memset(&cp, 0, sizeof(cp));
+
+ mgmt_send(adapter->mgmt, MGMT_OP_REMOVE_UUID, adapter->index,
+ sizeof(cp), &cp, NULL, NULL, NULL);
+}
+
static void read_info_complete(uint8_t status, uint16_t length, const void *param,
void *user_data)
{
@@ -1248,6 +1259,8 @@ static void read_info_complete(uint8_t status, uint16_t length, const void *para
/* TODO: Register all event notification handlers */
register_mgmt_handlers();
+ clear_uuids();
+
load_link_keys(NULL);
set_io_capability();
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 2/5] android: Remove not needed include
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
bt_uuid_t is not used so lib/uuid.h doesn't need to be included.
---
android/adapter.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/android/adapter.c b/android/adapter.c
index ac5878b..92949f9 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -38,7 +38,6 @@
#include "src/eir.h"
#include "lib/sdp.h"
#include "lib/sdp_lib.h"
-#include "lib/uuid.h"
#include "src/sdp-client.h"
#include "src/sdpd.h"
#include "log.h"
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 1/5] android: Add and remove sdp records and uuids
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcin Kraglak
In-Reply-To: <1384270586-9853-1-git-send-email-szymon.janc@tieto.com>
From: Marcin Kraglak <marcin.kraglak@tieto.com>
This is api for adding and removing sdp records and uuids
via mgmt interface. Local profiles have to store handle to
own records to remove them in cleanup. Additionally list of
uuids is created in bt_adapter struct.
---
android/adapter.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
android/adapter.h | 3 ++
2 files changed, 116 insertions(+)
diff --git a/android/adapter.c b/android/adapter.c
index 65b3170..ac5878b 100644
--- a/android/adapter.c
+++ b/android/adapter.c
@@ -40,6 +40,7 @@
#include "lib/sdp_lib.h"
#include "lib/uuid.h"
#include "src/sdp-client.h"
+#include "src/sdpd.h"
#include "log.h"
#include "hal-msg.h"
#include "ipc.h"
@@ -74,6 +75,7 @@ struct bt_adapter {
bool discovering;
uint32_t discoverable_timeout;
+ GSList *uuids;
};
struct browse_req {
@@ -986,6 +988,117 @@ static void load_link_keys(GSList *keys)
}
}
+/* output uint128 is in host order */
+static void uuid16_to_uint128(uint16_t uuid, uint128_t *u128)
+{
+ uuid_t uuid16, uuid128;
+
+ sdp_uuid16_create(&uuid16, uuid);
+ sdp_uuid16_to_uuid128(&uuid128, &uuid16);
+
+ ntoh128(&uuid128.value.uuid128, u128);
+}
+
+static void remove_uuid_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ if (status != MGMT_STATUS_SUCCESS) {
+ error("Failed to remove UUID: %s (0x%02x)",
+ mgmt_errstr(status), status);
+ return;
+ }
+
+ mgmt_dev_class_changed_event(adapter->index, length, param, NULL);
+}
+
+static void remove_uuid(uint16_t uuid)
+{
+ uint128_t uint128;
+ struct mgmt_cp_remove_uuid cp;
+
+ uuid16_to_uint128(uuid, &uint128);
+ htob128(&uint128, (uint128_t *) cp.uuid);
+
+ mgmt_send(adapter->mgmt, MGMT_OP_REMOVE_UUID,
+ adapter->index, sizeof(cp), &cp,
+ remove_uuid_complete, NULL, NULL);
+}
+
+static void add_uuid_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ if (status != MGMT_STATUS_SUCCESS) {
+ error("Failed to add UUID: %s (0x%02x)",
+ mgmt_errstr(status), status);
+ return;
+ }
+
+ mgmt_dev_class_changed_event(adapter->index, length, param, NULL);
+}
+
+static void add_uuid(uint8_t svc_hint, uint16_t uuid)
+{
+ uint128_t uint128;
+ struct mgmt_cp_add_uuid cp;
+
+ uuid16_to_uint128(uuid, &uint128);
+
+ htob128(&uint128, (uint128_t *) cp.uuid);
+ cp.svc_hint = svc_hint;
+
+ mgmt_send(adapter->mgmt, MGMT_OP_ADD_UUID,
+ adapter->index, sizeof(cp), &cp,
+ add_uuid_complete, NULL, NULL);
+}
+
+int bt_adapter_add_record(sdp_record_t *rec, uint8_t svc_hint)
+{
+ uint16_t uuid;
+
+ /* TODO support all types? */
+ if (rec->svclass.type != SDP_UUID16) {
+ warn("Ignoring unsupported UUID type");
+ return -EINVAL;
+ }
+
+ uuid = rec->svclass.value.uuid16;
+
+ if (g_slist_find(adapter->uuids, GUINT_TO_POINTER(uuid))) {
+ DBG("UUID 0x%x already added", uuid);
+ return -EALREADY;
+ }
+
+ adapter->uuids = g_slist_prepend(adapter->uuids,
+ GUINT_TO_POINTER(uuid));
+
+ add_uuid(svc_hint, uuid);
+
+ return add_record_to_server(&adapter->bdaddr, rec);
+}
+
+void bt_adapter_remove_record(uint32_t handle)
+{
+ sdp_record_t *rec;
+ GSList *uuid_found;
+ uint16_t uuid;
+
+ rec = sdp_record_find(handle);
+ if (!rec)
+ return;
+
+ uuid = rec->svclass.value.uuid16;
+
+ uuid_found = g_slist_find(adapter->uuids, GUINT_TO_POINTER(uuid));
+ if (uuid_found) {
+ remove_uuid(uuid);
+
+ adapter->uuids = g_slist_remove(adapter->uuids,
+ uuid_found->data);
+ }
+
+ remove_record_from_server(handle);
+}
+
static void set_mode_complete(uint8_t status, uint16_t length,
const void *param, void *user_data)
{
diff --git a/android/adapter.h b/android/adapter.h
index c62b859..0e84cb0 100644
--- a/android/adapter.h
+++ b/android/adapter.h
@@ -32,3 +32,6 @@ const bdaddr_t *bt_adapter_get_address(void);
bool bt_adapter_register(int sk);
void bt_adapter_unregister(void);
+
+int bt_adapter_add_record(sdp_record_t *rec, uint8_t svc_hint);
+void bt_adapter_remove_record(uint32_t handle);
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 0/5] Add support for registering local SDP records
From: Szymon Janc @ 2013-11-12 15:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
v3:
- fixed Johan comments
V2:
- don't use bt_uuid_t
- few bugfixes
V1 cover:
This adds support for manipulating local SDP database with
bt_adapter_add_record and bt_adapter_remove_record functions. Those should
be called when HAL service is registered or unregistered.
This also adds DeviceID record as at least 1 local UUID is needed by Android to
properly handle remote device profiles.
Last but not least: With this serie it is possible to connect HID device from
Android UI (Settings application). \O/
--
BR
Szymon Janc
Marcin Kraglak (3):
android: Add and remove sdp records and uuids
android: Clear adapter uuids during initialization
android: Add support for getting UUIDs property
Szymon Janc (2):
android: Remove not needed include
android: Register DeviceID record when adapter is initialized
android/adapter.c | 202 ++++++++++++++++++++++++++++++++++++++++++++++++++----
android/adapter.h | 3 +
2 files changed, 192 insertions(+), 13 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH_v2 3/3] android/hidhost: Set info request from HAL is not supported
From: Ravi kumar Veeramally @ 2013-11-12 15:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384268835-7570-1-git-send-email-ravikumar.veeramally@linux.intel.com>
Data from hal_cmd_hidhost_set_info is usefull only when we create
UHID device. Once device is created all the transactions will be
done through the fd. There is no way to use this information
once device is created with HID internals.
---
android/hidhost.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/android/hidhost.c b/android/hidhost.c
index 556e5a5..95a98c3 100644
--- a/android/hidhost.c
+++ b/android/hidhost.c
@@ -839,9 +839,13 @@ static uint8_t bt_hid_virtual_unplug(struct hal_cmd_hidhost_virtual_unplug *cmd,
static uint8_t bt_hid_info(struct hal_cmd_hidhost_set_info *cmd, uint16_t len)
{
- DBG("Not Implemented");
+ /* Data from hal_cmd_hidhost_set_info is usefull only when we create
+ * UHID device. Once device is created all the transactions will be
+ * done through the fd. There is no way to use this information
+ * once device is created with HID internals. */
+ DBG("Not supported");
- return HAL_STATUS_FAILED;
+ return HAL_STATUS_UNSUPPORTED;
}
static uint8_t bt_hid_get_protocol(struct hal_cmd_hidhost_get_protocol *cmd,
--
1.8.3.2
^ permalink raw reply related
* [PATCH_v2 2/3] android/hidhost: Remove deprecated idle opcode from ipc document
From: Ravi kumar Veeramally @ 2013-11-12 15:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384268835-7570-1-git-send-email-ravikumar.veeramally@linux.intel.com>
Idle time is deprecated in HID_SPEC1_1. So get and set idle time api's
are removed and not implemented. But callback is left out in Android
bt_hh.h. Generally this callback needs to be called when HAL requests
get and set idle time calls with status. So the method calls itself
removed, no point to implement this callback.
Also update GET_REPORT and VIRTUAL_UNPLUG opcode values.
---
android/hal-ipc-api.txt | 10 ++--------
android/hal-msg.h | 4 ++--
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 91ea280..57f4c13 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -614,20 +614,14 @@ Notifications:
0x01 = Boot
0xff = Unsupported
- Opcode 0x84 - Idle Time notification
-
- Notification parameters: Remote address (6 octets)
- Status (1 octet)
- Idle time (2 octets)
-
- Opcode 0x85 - Get Report notification
+ Opcode 0x84 - Get Report notification
Notification parameters: Remote address (6 octets)
Status (1 octet)
Report length (2 octets)
Report data (variable)
- Opcode 0x86 - Virtual Unplug notification
+ Opcode 0x85 - Virtual Unplug notification
Notification parameters: Remote address (6 octets)
Status (1 octet)
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 4dfd555..847cc1f 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -499,7 +499,7 @@ struct hal_ev_hidhost_proto_mode {
uint8_t mode;
} __attribute__((packed));
-#define HAL_EV_HIDHOST_GET_REPORT 0x85
+#define HAL_EV_HIDHOST_GET_REPORT 0x84
struct hal_ev_hidhost_get_report {
uint8_t bdaddr[6];
uint8_t status;
@@ -507,7 +507,7 @@ struct hal_ev_hidhost_get_report {
uint8_t data[0];
} __attribute__((packed));
-#define HAL_EV_HIDHOST_VIRTUAL_UNPLUG 0x86
+#define HAL_EV_HIDHOST_VIRTUAL_UNPLUG 0x85
struct hal_ev_hidhost_virtual_unplug {
uint8_t bdaddr[6];
uint8_t status;
--
1.8.3.2
^ permalink raw reply related
* [PATCH_v2 1/3] android/hidhost: Handle uhid output and feature events
From: Ravi kumar Veeramally @ 2013-11-12 15:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
Data read on uhid events output and feature has to be send through
SET_REPORT request to HID device.
---
android/hidhost.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/android/hidhost.c b/android/hidhost.c
index cba80a6..556e5a5 100644
--- a/android/hidhost.c
+++ b/android/hidhost.c
@@ -155,7 +155,30 @@ static void hid_device_free(struct hid_device *dev)
static void handle_uhid_event(struct hid_device *dev, struct uhid_event *ev)
{
- DBG("UHID_OUTPUT UHID_FEATURE unsupported");
+ int fd, i;
+ uint8_t *req = NULL;
+ uint8_t req_size = 0;
+
+ if (!(dev->ctrl_io))
+ return;
+
+ req_size = 1 + (ev->u.output.size / 2);
+ req = g_try_malloc0(req_size);
+ if (!req)
+ return;
+
+ req[0] = HID_MSG_SET_REPORT | ev->u.output.rtype;
+ for (i = 0; i < (req_size - 1); i++)
+ sscanf((char *) &(ev->u.output.data)[i * 2],
+ "%hhx", &(req + 1)[i]);
+
+ fd = g_io_channel_unix_get_fd(dev->ctrl_io);
+
+ if (write(fd, req, req_size) < 0)
+ error("error writing set_report: %s (%d)",
+ strerror(errno), errno);
+
+ g_free(req);
}
static gboolean uhid_event_cb(GIOChannel *io, GIOCondition cond,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2 BlueZ] core: Do not attempt to connect if adapter is not powered
From: Johan Hedberg @ 2013-11-12 14:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1384266749-309-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Nov 12, 2013, Luiz Augusto von Dentz wrote:
> If the adapter is not yet powered do not attempt to connect, also
> abort any connection attempt in case of error -EHOSTUNREACH is returned
> by the kernel which also means the adapter is not up or in case of
> -ECONNABORTED which means the adapter was powered down during the
> connection attempt.
> ---
> v2: Add better description, add comments what each error code means and
> treat -ECONNABORTED.
>
> src/device.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* [PATCH v2 BlueZ] core: Do not attempt to connect if adapter is not powered
From: Luiz Augusto von Dentz @ 2013-11-12 14:32 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If the adapter is not yet powered do not attempt to connect, also
abort any connection attempt in case of error -EHOSTUNREACH is returned
by the kernel which also means the adapter is not up or in case of
-ECONNABORTED which means the adapter was powered down during the
connection attempt.
---
v2: Add better description, add comments what each error code means and
treat -ECONNABORTED.
src/device.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/device.c b/src/device.c
index 60efd62..662ba26 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1156,8 +1156,15 @@ static void device_profile_connected(struct btd_device *dev,
if (dev->pending == NULL)
return;
- if (!dev->connected && err == -EHOSTDOWN)
- goto done;
+ if (!dev->connected) {
+ switch (-err) {
+ case EHOSTDOWN: /* page timeout */
+ case EHOSTUNREACH: /* adapter not powered */
+ case ECONNABORTED: /* adapter powered down */
+ goto done;
+ }
+ }
+
pending = dev->pending->data;
l = find_service_with_profile(dev->pending, profile);
@@ -1322,6 +1329,9 @@ static DBusMessage *connect_profiles(struct btd_device *dev, DBusMessage *msg,
if (dev->pending || dev->connect || dev->browse)
return btd_error_in_progress(msg);
+ if (!btd_adapter_get_powered(dev->adapter))
+ return btd_error_not_ready(msg);
+
device_set_temporary(dev, FALSE);
if (!dev->svc_resolved)
--
1.8.3.1
^ permalink raw reply related
* [PATCH_v2 4/4] android/pan: Handle connection and control state notifications
From: Ravi kumar Veeramally @ 2013-11-12 14:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384266042-6344-1-git-send-email-ravikumar.veeramally@linux.intel.com>
---
android/hal-pan.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/android/hal-pan.c b/android/hal-pan.c
index 78d526c..595cde9 100644
--- a/android/hal-pan.c
+++ b/android/hal-pan.c
@@ -31,10 +31,41 @@ static bool interface_ready(void)
return cbs != NULL;
}
+static void handle_conn_state(void *buf)
+{
+ struct hal_ev_pan_conn_state *ev = buf;
+
+ if (cbs->connection_state_cb)
+ cbs->connection_state_cb(ev->state, ev->status,
+ (bt_bdaddr_t *) ev->bdaddr,
+ ev->local_role, ev->remote_role);
+}
+
+static void handle_ctrl_state(void *buf)
+{
+ struct hal_ev_pan_ctrl_state *ev = buf;
+
+ if (cbs->control_state_cb)
+ cbs->control_state_cb(ev->state, ev->status,
+ ev->local_role, (char *)ev->name);
+}
+
void bt_notify_pan(uint16_t opcode, void *buf, uint16_t len)
{
if (!interface_ready())
return;
+
+ switch (opcode) {
+ case HAL_EV_PAN_CONN_STATE:
+ handle_conn_state(buf);
+ break;
+ case HAL_EV_PAN_CTRL_STATE:
+ handle_ctrl_state(buf);
+ break;
+ default:
+ DBG("Unhandled callback opcode=0x%x", opcode);
+ break;
+ }
}
static bt_status_t pan_enable(int local_role)
--
1.8.3.2
^ permalink raw reply related
* [PATCH_v2 3/4] android/pan: Add notify method to PAN notifications
From: Ravi kumar Veeramally @ 2013-11-12 14:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ravi kumar Veeramally
In-Reply-To: <1384266042-6344-1-git-send-email-ravikumar.veeramally@linux.intel.com>
---
android/hal-pan.c | 6 ++++++
android/hal.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/android/hal-pan.c b/android/hal-pan.c
index bec179f..78d526c 100644
--- a/android/hal-pan.c
+++ b/android/hal-pan.c
@@ -31,6 +31,12 @@ static bool interface_ready(void)
return cbs != NULL;
}
+void bt_notify_pan(uint16_t opcode, void *buf, uint16_t len)
+{
+ if (!interface_ready())
+ return;
+}
+
static bt_status_t pan_enable(int local_role)
{
struct hal_cmd_pan_enable cmd;
diff --git a/android/hal.h b/android/hal.h
index 2ce7932..be5d491 100644
--- a/android/hal.h
+++ b/android/hal.h
@@ -31,3 +31,4 @@ void bt_thread_associate(void);
void bt_thread_disassociate(void);
void bt_notify_hidhost(uint16_t opcode, void *buf, uint16_t len);
void bt_notify_a2dp(uint16_t opcode, void *buf, uint16_t len);
+void bt_notify_pan(uint16_t opcode, void *buf, uint16_t len);
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox