* sdptool hanging remote
From: Grahame Jordan @ 2010-11-23 5:37 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I am using bluez-4.77 on a Gumstix Verdex kernel 2.4.32 patch 21
When I run:
sdptool records 00:80:37:2F:06:08"
from the Workstation Ubuntu 10.04 Bluez-4.6? to the Gumstix the Gumstix
hangs.
It does not hang completely but is very busy. It hangs for about 20
seconds and then releases for about 1 second
before it locks up again.
I have tried this on several different Gumstix with the same issue.
Changing workstations from Ubuntu 10.04 to Ubuntu 8.04 does make a
difference.
From Ubuntu 8.04 there seems to be no problem. blue-utils 3.26?
Appreciate help
Thanks
Grahame Jordan
^ permalink raw reply
* Re: [PATCH] Fix managing dbus filters depending on BT state
From: Bartosz Szatkowski @ 2010-11-22 23:17 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTin5t-=bMeBmAJ2A+hV4h=dXQeu5dNFbMby43ssS@mail.gmail.com>
On Mon, Nov 22, 2010 at 8:12 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Mon, Nov 22, 2010 at 4:33 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Bartosz,
>>
>> On Mon, Nov 22, 2010, Bartosz Szatkowski wrote:
>>> Previously even if BT was disabled, bluetoothd would handle some dbus
>>> singals (mostly connected with HFP). Now filters are added when
>>> BT is enabled and removed when BT is disabled.
>>> ---
>>> audio/manager.c | 4 ++--
>>> audio/telephony-dummy.c | 10 ++++++++++
>>> audio/telephony-maemo5.c | 10 ++++++++++
>>> audio/telephony-maemo6.c | 10 ++++++++++
>>> audio/telephony-ofono.c | 10 ++++++++++
>>> audio/telephony.h | 1 +
>>> src/adapter.c | 5 +++++
>>> 7 files changed, 48 insertions(+), 2 deletions(-)
>>
>> Nack on this one. I understand the issue you're trying to fix but it
>> needs to be done differently.
>>
>>> diff --git a/audio/manager.c b/audio/manager.c
>>> index 816c807..2fc7bf1 100644
>>> --- a/audio/manager.c
>>> +++ b/audio/manager.c
>>> @@ -1178,7 +1178,7 @@ proceed:
>>> btd_register_adapter_driver(&media_server_driver);
>>>
>>> if (enabled.headset) {
>>> - telephony_init();
>>> + telephony_set_state(1);
>>> btd_register_adapter_driver(&headset_server_driver);
>>> }
>>
>> If you're gonna call this "state" you should have proper defines or
>> enums for the values, however in this case it's essentially a boolean so
>> that's not necessary. In fact since it's a boolean you don't even need
>> to have any new function or variable at all for it: just use
>> telephony_init and telephony_exit.
>>
>>> --- a/src/adapter.c
>>> +++ b/src/adapter.c
>>> @@ -57,6 +57,7 @@
>>> #include "glib-helper.h"
>>> #include "agent.h"
>>> #include "storage.h"
>>> +#include "../audio/telephony.h"
>>>
>>> #define IO_CAPABILITY_DISPLAYONLY 0x00
>>> #define IO_CAPABILITY_DISPLAYYESNO 0x01
>>> @@ -2404,6 +2405,8 @@ int adapter_start(struct btd_adapter *adapter)
>>>
>>> err = adapter_up(adapter, mode);
>>>
>>> + telephony_init();
>>> +
>>
>> This is just wrong. The core daemon should never have direct access to
>> the telephony driver. Instead, you should have the audio plugin
>> (probably audio/manager.c or audio/headset.c) register a adapter powered
>> callback and then call telehony_init/exit from that callback.
>
> I have an almost working version of this using adapter drivers and
> powered changes via callback registration, the tricky part here is how
> to detect when to do headset_init/headset_exit since those should be
> called only once. I didn't know there somebody working on this but
> anyway I gonna try to finish this asap.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
Hi Luiz,
please fell free to send it (no hard fillings :) ) Ive just getting to
know bluez so probably it would take me a while to get through whole
plugin/callback subsystem.
--
Pozdrowienia,
Bartosz Szatkowski
^ permalink raw reply
* [PATCH] Add a runtime option to set the BCSP communication rate
From: Wade Brown @ 2010-11-22 23:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Wade Brown
---
tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
tools/csr.h | 3 ++-
tools/csr_bcsp.c | 4 ++--
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/tools/bccmd.c b/tools/bccmd.c
index 686e858..5cb9255 100644
--- a/tools/bccmd.c
+++ b/tools/bccmd.c
@@ -59,7 +59,7 @@
#define CSR_TYPE_ARRAY CSR_TYPE_COMPLEX
#define CSR_TYPE_BDADDR CSR_TYPE_COMPLEX
-static inline int transport_open(int transport, char *device)
+static inline int transport_open(int transport, char *device, speed_t bcsp_rate)
{
switch (transport) {
case CSR_TRANSPORT_HCI:
@@ -69,7 +69,7 @@ static inline int transport_open(int transport, char *device)
return csr_open_usb(device);
#endif
case CSR_TRANSPORT_BCSP:
- return csr_open_bcsp(device);
+ return csr_open_bcsp(device, bcsp_rate);
case CSR_TRANSPORT_H4:
return csr_open_h4(device);
case CSR_TRANSPORT_3WIRE:
@@ -1109,6 +1109,7 @@ static void usage(void)
printf("Options:\n"
"\t-t <transport> Select the transport\n"
"\t-d <device> Select the device\n"
+ "\t-b <bcsp rate> Select the bcsp transfer rate\n"
"\t-h, --help Display help\n"
"\n");
@@ -1137,6 +1138,7 @@ static void usage(void)
static struct option main_options[] = {
{ "transport", 1, 0, 't' },
{ "device", 1, 0, 'd' },
+ { "bcsprate", 1, 0, 'b'},
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
};
@@ -1145,8 +1147,9 @@ int main(int argc, char *argv[])
{
char *device = NULL;
int i, err, opt, transport = CSR_TRANSPORT_HCI;
+ speed_t bcsp_rate = B38400;
- while ((opt=getopt_long(argc, argv, "+t:d:i:h", main_options, NULL)) != EOF) {
+ while ((opt=getopt_long(argc, argv, "+t:d:i:b:h", main_options, NULL)) != EOF) {
switch (opt) {
case 't':
if (!strcasecmp(optarg, "hci"))
@@ -1171,7 +1174,39 @@ int main(int argc, char *argv[])
case 'i':
device = strdup(optarg);
break;
-
+ case 'b':
+ switch (atoi(optarg)) {
+ case 9600: bcsp_rate = B9600; break;
+ case 19200: bcsp_rate = B19200; break;
+ case 38400: bcsp_rate = B38400; break;
+ case 57600: bcsp_rate = B57600; break;
+ case 115200: bcsp_rate = B115200; break;
+ case 230400: bcsp_rate = B230400; break;
+ case 460800: bcsp_rate = B460800; break;
+ case 500000: bcsp_rate = B500000; break;
+ case 576000: bcsp_rate = B576000; break;
+ case 921600: bcsp_rate = B921600; break;
+ case 1000000: bcsp_rate = B1000000; break;
+ case 1152000: bcsp_rate = B1152000; break;
+ case 1500000: bcsp_rate = B1500000; break;
+ case 2000000: bcsp_rate = B2000000; break;
+#ifdef B2500000
+ case 2500000: bcsp_rate = B2500000; break;
+#endif
+#ifdef B3000000
+ case 3000000: bcsp_rate = B3000000; break;
+#endif
+#ifdef B3500000
+ case 3500000: bcsp_rate = B3500000; break;
+#endif
+#ifdef B4000000
+ case 4000000: bcsp_rate = B4000000; break;
+#endif
+ default:
+ printf("Unknown BCSP baud rate specified, defaulting to 38400bps\n");
+ bcsp_rate = B38400;
+ }
+ break;
case 'h':
default:
usage();
@@ -1188,7 +1223,7 @@ int main(int argc, char *argv[])
exit(1);
}
- if (transport_open(transport, device) < 0)
+ if (transport_open(transport, device, bcsp_rate) < 0)
exit(1);
if (device)
diff --git a/tools/csr.h b/tools/csr.h
index 1d70491..8b94d7b 100644
--- a/tools/csr.h
+++ b/tools/csr.h
@@ -22,6 +22,7 @@
*/
#include <stdint.h>
+#include <termios.h>
#define CSR_VARID_PS_CLR_ALL 0x000b /* valueless */
#define CSR_VARID_PS_FACTORY_SET 0x000c /* valueless */
@@ -519,7 +520,7 @@ int csr_read_usb(uint16_t varid, uint8_t *value, uint16_t length);
int csr_write_usb(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_usb(void);
-int csr_open_bcsp(char *device);
+int csr_open_bcsp(char *device, speed_t bcsp_rate);
int csr_read_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
int csr_write_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_bcsp(void);
diff --git a/tools/csr_bcsp.c b/tools/csr_bcsp.c
index e551311..df247a2 100644
--- a/tools/csr_bcsp.c
+++ b/tools/csr_bcsp.c
@@ -46,7 +46,7 @@ static uint8_t send_buffer[512];
static struct ubcsp_packet receive_packet;
static uint8_t receive_buffer[512];
-int csr_open_bcsp(char *device)
+int csr_open_bcsp(char *device, speed_t bcsp_rate)
{
struct termios ti;
uint8_t delay, activity = 0x00;
@@ -84,7 +84,7 @@ int csr_open_bcsp(char *device)
ti.c_cc[VMIN] = 1;
ti.c_cc[VTIME] = 0;
- cfsetospeed(&ti, B38400);
+ cfsetospeed(&ti, bcsp_rate);
if (tcsetattr(fd, TCSANOW, &ti) < 0) {
fprintf(stderr, "Can't change port settings: %s (%d)\n",
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH] Fix typo in adapter documentation
From: Johan Hedberg @ 2010-11-22 22:07 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1290452756-7967-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Mon, Nov 22, 2010, Jose Antonio Santos Cadenas wrote:
> ---
> doc/adapter-api.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
> index 65e2887..f287f29 100644
> --- a/doc/adapter-api.txt
> +++ b/doc/adapter-api.txt
> @@ -148,7 +148,7 @@ Methods dict GetProperties()
>
> This registers the adapter wide agent.
>
> - The object path defines the path the of the agent
> + The object path defines the path of the agent
> that will be called when user input is needed.
>
> If an application disconnects from the bus all
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: pull request: bluetooth-2.6 2010-11-22
From: Johan Hedberg @ 2010-11-22 22:03 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: John W. Linville, linux-wireless, linux-bluetooth
In-Reply-To: <20101122201330.GE23109@vigoh>
Hi,
On Mon, Nov 22, 2010, Gustavo F. Padovan wrote:
> > The other fixes are larger than I would like to see. What is the
> > effect of the bug? Does the Bluetooth controller stop completely?
> > Does it cause a crash?
> >
> > Is this a newly-introduced bug? Or one that has been around for
> > a while?
>
> No, it is not serious like that. By not having this patch we won't have
> the remote name request command during connection setup, The remote name
> request was done by bluetoothd, but we already removed it from
> userspace. It is not a really big problem once we also cache the remote
> devices names in bluetoothd.
> So I'm seeing no way to convince you tou pull this patch (actually I'm
> now also covinced to queue this to bluetooth-next). I'll sent a new
> pull request soon, after wait some time for new patches.
IIRC the symptom that prompted the initial investigation was the failure
to properly connect to one specific Bluetooth headset. After discussions
with Marcel the conculsion was to move more control of these commands to
the kernel side. OTOH, this is certainly not the first time a BT
controller chokes up when receiving too many commands at the same time
(I've seen this several times during the last 8 years or so that I've
been involved with Bluetooth). Anyway, I agree that this might be better
suited for bluetooth-next.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Automate remote name requests
From: Johan Hedberg @ 2010-11-22 21:51 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Arun K. Singh, linux-bluetooth
In-Reply-To: <AANLkTikHPWyjS+m2NMrxcL0FP6WhX+APExNELRuw4=Pe@mail.gmail.com>
Hi Luiz,
On Mon, Nov 22, 2010, Luiz Augusto von Dentz wrote:
> >> Could you be bit more explicit about such user space versions that you
> >> recommend? Would latest bluez versions such as 4.80 qualify for your
> >> recommendation?
> >
> > The automated name requests upon "connect complete" events were removed
> > in 4.78 so any version from there onwards would qualify.
>
> Maybe there is some way to detect that the kernel is not doing it, or
> at least force bluetoothd to resolve once to make sure it can be used
> with older kernel versions so it doesn't have to always update as it
> was used to be but if we are to authenticate or authorize a device it
> should have a name so the ui can display it to the user.
Regarding the kernel version detection, this was certainly considered
but there doesn't seem to be any simple way to do it. However, now that
you mention it, this can certainly be an inconvenient issue with
incoming connections for devices which we've never seen during a device
discovery. Therefore, some kind of a userspace workaround for this would
imho be desirable and I'd certainly be willing to accept a patch for it
as long as it doesn't get too complicated. I suppose it's sufficient if
the patch would be for hciops only since any system running mgmtops
would also have a kernel that does the name request.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Automate remote name requests
From: Luiz Augusto von Dentz @ 2010-11-22 20:35 UTC (permalink / raw)
To: Arun K. Singh, linux-bluetooth
In-Reply-To: <20101122071243.GA23443@jh-x301>
Hi Johan,
On Mon, Nov 22, 2010 at 9:12 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Arun,
>
> On Mon, Nov 22, 2010, Arun K. Singh wrote:
>> > The code will work sub-optimally with userspace versions that still
>> > do the name requesting themselves (it shouldn't break anything
>> > though) so it is recommended to combine this with a userspace
>> > software version that doesn't have automated name requests.
>>
>> Could you be bit more explicit about such user space versions that you
>> recommend? Would latest bluez versions such as 4.80 qualify for your
>> recommendation?
>
> The automated name requests upon "connect complete" events were removed
> in 4.78 so any version from there onwards would qualify.
Maybe there is some way to detect that the kernel is not doing it, or
at least force bluetoothd to resolve once to make sure it can be used
with older kernel versions so it doesn't have to always update as it
was used to be but if we are to authenticate or authorize a device it
should have a name so the ui can display it to the user.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: pull request: bluetooth-2.6 2010-11-22
From: Gustavo F. Padovan @ 2010-11-22 20:13 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, linux-bluetooth
In-Reply-To: <20101122193029.GE2117@tuxdriver.com>
* John W. Linville <linville@tuxdriver.com> [2010-11-22 14:30:30 -0500]:
> On Mon, Nov 22, 2010 at 04:14:11PM -0200, Gustavo F. Padovan wrote:
> > Hi John,
> >
> > Following batch is intended to 2.6.37, it includes a very trivial return
> > err fix from myself and an remote name request fix from Johan Hedberg.
> > This fix move the remote name request (during the connection creation
> > process) to the kernelspace. In addition we have removed this operation
> > from BlueZ in userspace. Quoting part of Johan's patch which already
> > explain the change:
> >
> > "So far userspace has been responsible for this extra name request but
> > tighter control is needed in order not to flood Bluetooth controllers
> > with two many commands during connection creation. It has been shown
> > that some controllers simply fail to function correctly if they get too
> > many (almost) simultaneous commands during connection creation. The
> > simplest way to acheive better control of these commands is to move
> > their sending completely to the kernel side."
> >
> > As side effect, we have a clean up patch in preparation to this fix.
> >
> > Please pull, or let me know any problems you find here. Thanks.
>
> The return code fix seems reasonable -- small and obvious, etc.
>
> The other fixes are larger than I would like to see. What is the
> effect of the bug? Does the Bluetooth controller stop completely?
> Does it cause a crash?
>
> Is this a newly-introduced bug? Or one that has been around for
> a while?
No, it is not serious like that. By not having this patch we won't have
the remote name request command during connection setup, The remote name
request was done by bluetoothd, but we already removed it from
userspace. It is not a really big problem once we also cache the remote
devices names in bluetoothd.
So I'm seeing no way to convince you tou pull this patch (actually I'm
now also covinced to queue this to bluetooth-next). I'll sent a new
pull request soon, after wait some time for new patches.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Fix managing dbus filters depending on BT state
From: Luiz Augusto von Dentz @ 2010-11-22 20:12 UTC (permalink / raw)
To: Bartosz Szatkowski, linux-bluetooth
In-Reply-To: <20101122143345.GA2303@jh-x301>
Hi,
On Mon, Nov 22, 2010 at 4:33 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Bartosz,
>
> On Mon, Nov 22, 2010, Bartosz Szatkowski wrote:
>> Previously even if BT was disabled, bluetoothd would handle some dbus
>> singals (mostly connected with HFP). Now filters are added when
>> BT is enabled and removed when BT is disabled.
>> ---
>> audio/manager.c | 4 ++--
>> audio/telephony-dummy.c | 10 ++++++++++
>> audio/telephony-maemo5.c | 10 ++++++++++
>> audio/telephony-maemo6.c | 10 ++++++++++
>> audio/telephony-ofono.c | 10 ++++++++++
>> audio/telephony.h | 1 +
>> src/adapter.c | 5 +++++
>> 7 files changed, 48 insertions(+), 2 deletions(-)
>
> Nack on this one. I understand the issue you're trying to fix but it
> needs to be done differently.
>
>> diff --git a/audio/manager.c b/audio/manager.c
>> index 816c807..2fc7bf1 100644
>> --- a/audio/manager.c
>> +++ b/audio/manager.c
>> @@ -1178,7 +1178,7 @@ proceed:
>> btd_register_adapter_driver(&media_server_driver);
>>
>> if (enabled.headset) {
>> - telephony_init();
>> + telephony_set_state(1);
>> btd_register_adapter_driver(&headset_server_driver);
>> }
>
> If you're gonna call this "state" you should have proper defines or
> enums for the values, however in this case it's essentially a boolean so
> that's not necessary. In fact since it's a boolean you don't even need
> to have any new function or variable at all for it: just use
> telephony_init and telephony_exit.
>
>> --- a/src/adapter.c
>> +++ b/src/adapter.c
>> @@ -57,6 +57,7 @@
>> #include "glib-helper.h"
>> #include "agent.h"
>> #include "storage.h"
>> +#include "../audio/telephony.h"
>>
>> #define IO_CAPABILITY_DISPLAYONLY 0x00
>> #define IO_CAPABILITY_DISPLAYYESNO 0x01
>> @@ -2404,6 +2405,8 @@ int adapter_start(struct btd_adapter *adapter)
>>
>> err = adapter_up(adapter, mode);
>>
>> + telephony_init();
>> +
>
> This is just wrong. The core daemon should never have direct access to
> the telephony driver. Instead, you should have the audio plugin
> (probably audio/manager.c or audio/headset.c) register a adapter powered
> callback and then call telehony_init/exit from that callback.
I have an almost working version of this using adapter drivers and
powered changes via callback registration, the tricky part here is how
to detect when to do headset_init/headset_exit since those should be
called only once. I didn't know there somebody working on this but
anyway I gonna try to finish this asap.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] ath3k: reduce memory usage
From: Alexander Holler @ 2010-11-22 20:09 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Alicke Xu, Luis R. Rodriguez, Vikram Kandukuri, linux-bluetooth,
Alexander Holler
There is no need to hold the firmware in memory.
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/bluetooth/ath3k.c | 75 ++++++++++++---------------------------------
1 files changed, 20 insertions(+), 55 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 128cae4..81cd1ed 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -43,46 +43,40 @@ MODULE_DEVICE_TABLE(usb, ath3k_table);
#define USB_REQ_DFU_DNLOAD 1
#define BULK_SIZE 4096
-struct ath3k_data {
- struct usb_device *udev;
- u8 *fw_data;
- u32 fw_size;
- u32 fw_sent;
-};
-
-static int ath3k_load_firmware(struct ath3k_data *data,
- unsigned char *firmware,
- int count)
+static int ath3k_load_firmware(struct usb_device *udev,
+ const struct firmware *firmware)
{
u8 *send_buf;
int err, pipe, len, size, sent = 0;
+ int count = firmware->size;
- BT_DBG("ath3k %p udev %p", data, data->udev);
+ BT_DBG("udev %p", udev);
- pipe = usb_sndctrlpipe(data->udev, 0);
+ pipe = usb_sndctrlpipe(udev, 0);
- if ((usb_control_msg(data->udev, pipe,
+ send_buf = kmalloc(BULK_SIZE, GFP_ATOMIC);
+ if (!send_buf) {
+ BT_ERR("Can't allocate memory chunk for firmware");
+ return -ENOMEM;
+ }
+
+ memcpy(send_buf, firmware->data, 20);
+ if ((err = usb_control_msg(udev, pipe,
USB_REQ_DFU_DNLOAD,
USB_TYPE_VENDOR, 0, 0,
- firmware, 20, USB_CTRL_SET_TIMEOUT)) < 0) {
+ send_buf, 20, USB_CTRL_SET_TIMEOUT)) < 0) {
BT_ERR("Can't change to loading configuration err");
- return -EBUSY;
+ goto error;
}
sent += 20;
count -= 20;
- send_buf = kmalloc(BULK_SIZE, GFP_ATOMIC);
- if (!send_buf) {
- BT_ERR("Can't allocate memory chunk for firmware");
- return -ENOMEM;
- }
-
while (count) {
size = min_t(uint, count, BULK_SIZE);
- pipe = usb_sndbulkpipe(data->udev, 0x02);
- memcpy(send_buf, firmware + sent, size);
+ pipe = usb_sndbulkpipe(udev, 0x02);
+ memcpy(send_buf, firmware->data + sent, size);
- err = usb_bulk_msg(data->udev, pipe, send_buf, size,
+ err = usb_bulk_msg(udev, pipe, send_buf, size,
&len, 3000);
if (err || (len != size)) {
@@ -108,57 +102,28 @@ static int ath3k_probe(struct usb_interface *intf,
{
const struct firmware *firmware;
struct usb_device *udev = interface_to_usbdev(intf);
- struct ath3k_data *data;
- int size;
BT_DBG("intf %p id %p", intf, id);
if (intf->cur_altsetting->desc.bInterfaceNumber != 0)
return -ENODEV;
- data = kzalloc(sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
-
- data->udev = udev;
-
if (request_firmware(&firmware, "ath3k-1.fw", &udev->dev) < 0) {
- kfree(data);
return -EIO;
}
- size = max_t(uint, firmware->size, 4096);
- data->fw_data = kmalloc(size, GFP_KERNEL);
- if (!data->fw_data) {
+ if (ath3k_load_firmware(udev, firmware)) {
release_firmware(firmware);
- kfree(data);
- return -ENOMEM;
- }
-
- memcpy(data->fw_data, firmware->data, firmware->size);
- data->fw_size = firmware->size;
- data->fw_sent = 0;
- release_firmware(firmware);
-
- usb_set_intfdata(intf, data);
- if (ath3k_load_firmware(data, data->fw_data, data->fw_size)) {
- usb_set_intfdata(intf, NULL);
- kfree(data->fw_data);
- kfree(data);
return -EIO;
}
+ release_firmware(firmware);
return 0;
}
static void ath3k_disconnect(struct usb_interface *intf)
{
- struct ath3k_data *data = usb_get_intfdata(intf);
-
BT_DBG("ath3k_disconnect intf %p", intf);
-
- kfree(data->fw_data);
- kfree(data);
}
static struct usb_driver ath3k_driver = {
--
1.7.2.3
^ permalink raw reply related
* Re: pull request: bluetooth-2.6 2010-11-22
From: John W. Linville @ 2010-11-22 19:30 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-wireless, linux-bluetooth
In-Reply-To: <20101122181411.GD23109@vigoh>
On Mon, Nov 22, 2010 at 04:14:11PM -0200, Gustavo F. Padovan wrote:
> Hi John,
>
> Following batch is intended to 2.6.37, it includes a very trivial return
> err fix from myself and an remote name request fix from Johan Hedberg.
> This fix move the remote name request (during the connection creation
> process) to the kernelspace. In addition we have removed this operation
> from BlueZ in userspace. Quoting part of Johan's patch which already
> explain the change:
>
> "So far userspace has been responsible for this extra name request but
> tighter control is needed in order not to flood Bluetooth controllers
> with two many commands during connection creation. It has been shown
> that some controllers simply fail to function correctly if they get too
> many (almost) simultaneous commands during connection creation. The
> simplest way to acheive better control of these commands is to move
> their sending completely to the kernel side."
>
> As side effect, we have a clean up patch in preparation to this fix.
>
> Please pull, or let me know any problems you find here. Thanks.
The return code fix seems reasonable -- small and obvious, etc.
The other fixes are larger than I would like to see. What is the
effect of the bug? Does the Bluetooth controller stop completely?
Does it cause a crash?
Is this a newly-introduced bug? Or one that has been around for
a while?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 2/2] Fix: increment MDL and MCL reference counter in IO watchers.
From: Jose Antonio Santos Cadenas @ 2010-11-22 19:14 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20101122170525.GA13003@jh-x301>
2010/11/22 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi Jose,
>
> On Mon, Nov 22, 2010, Jose Antonio Santos Cadenas wrote:
>> When a io_watcher is added to an MDL or an MCL channel, its reference
>> should be incremented because the watcher should keep its own
>> reference the the structure.
>>
>> Also a destroy function is added in order to decrement the reference
>> once the watcher is removed.
>> ---
>> health/mcap.c | 28 +++++++++++++++++++---------
>> 1 files changed, 19 insertions(+), 9 deletions(-)
>
> Thanks. Pushed upstream, but I still had to tweak the summary line a
> little bit (take a look at the upstream tree if you're interested).
I have to avoid dots at the end of the commit message I always think
that, but sometimes my fingers are quicker than my mind. Sorry :) .
>
> Johan
>
^ permalink raw reply
* [PATCH] Fix typo in adapter documentation
From: Jose Antonio Santos Cadenas @ 2010-11-22 19:05 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
---
doc/adapter-api.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 65e2887..f287f29 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -148,7 +148,7 @@ Methods dict GetProperties()
This registers the adapter wide agent.
- The object path defines the path the of the agent
+ The object path defines the path of the agent
that will be called when user input is needed.
If an application disconnects from the bus all
--
1.7.1
^ permalink raw reply related
* pull request: bluetooth-2.6 2010-11-22
From: Gustavo F. Padovan @ 2010-11-22 18:14 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth
Hi John,
Following batch is intended to 2.6.37, it includes a very trivial return
err fix from myself and an remote name request fix from Johan Hedberg.
This fix move the remote name request (during the connection creation
process) to the kernelspace. In addition we have removed this operation
from BlueZ in userspace. Quoting part of Johan's patch which already
explain the change:
"So far userspace has been responsible for this extra name request but
tighter control is needed in order not to flood Bluetooth controllers
with two many commands during connection creation. It has been shown
that some controllers simply fail to function correctly if they get too
many (almost) simultaneous commands during connection creation. The
simplest way to acheive better control of these commands is to move
their sending completely to the kernel side."
As side effect, we have a clean up patch in preparation to this fix.
Please pull, or let me know any problems you find here. Thanks.
The following changes since commit 3bf30b56c4f0a1c4fae34050b7db4527c92891e8:
ath9k_htc: Avoid setting QoS control for non-QoS frames (2010-11-18 13:17:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Gustavo F. Padovan (1):
Bluetooth: Fix not returning proper error in SCO
Johan Hedberg (3):
Bluetooth: Simplify remote features callback function logic
Bluetooth: Create a unified authentication request function
Bluetooth: Automate remote name requests
net/bluetooth/hci_event.c | 153 ++++++++++++++++++++++++++++++++-------------
net/bluetooth/sco.c | 6 +-
2 files changed, 112 insertions(+), 47 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Fix error handling for l2cap_init()
From: Anderson Lizardo @ 2010-11-22 18:05 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20101122173447.GA23109@vigoh>
Hi Gustavo,
On Mon, Nov 22, 2010 at 1:34 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> * Anderson Lizardo <anderson.lizardo@openbossa.org> [2010-11-22 06:57:14 -0400]:
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index 18a802c..7980e24 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4875,8 +4875,10 @@ static int __init l2cap_init(void)
>> return err;
>>
>> _busy_wq = create_singlethread_workqueue("l2cap");
>> - if (!_busy_wq)
>> - goto error;
>> + if (!_busy_wq) {
>> + err = -ENOMEM;
>> + goto error_busy_wq;
>> + }
>
> I prefer if you move the workqueue creation to after the
> hci_register_proto block. That will make things easier.
I wonder if that might not introduce a race condition, because after
hci_register_proto() new connections may already arrive?
Or is it guaranteed to only happen after l2cap_init() has finished?
If not, I can make this change without problem.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Get ride of __rfcomm_get_sock_by_channel()
From: Gustavo F. Padovan @ 2010-11-22 17:44 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1290036176-4022-2-git-send-email-padovan@profusion.mobi>
* Gustavo F. Padovan <padovan@profusion.mobi> [2010-11-17 21:22:56 -0200]:
> rfcomm_get_sock_by_channel() was the only user of this function, so I merged
> both into rfcomm_get_sock_by_channel(). The socket lock now should be hold
> outside of rfcomm_get_sock_by_channel() once we hold and release it inside the
> same function now.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/rfcomm/sock.c | 19 +++++++------------
> 1 files changed, 7 insertions(+), 12 deletions(-)
I'm also pushing these two to bluetooth-next. It should be good as
nobody commented on it, or people don't looked to it since there is a
clear typo and in commit messase (ride -> rid)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: do not use assignment in if condition
From: Gustavo F. Padovan @ 2010-11-22 17:40 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1290424897-32463-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-11-22 13:21:37 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Fix checkpatch errors like:
> "ERROR: do not use assignment in if condition"
> Simplify code and fix one long line.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/hci_event.c | 18 ++++++++++++------
> 1 files changed, 12 insertions(+), 6 deletions(-)
Applied, thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: Fix error handling for l2cap_init()
From: Gustavo F. Padovan @ 2010-11-22 17:34 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1290423434-2920-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
* Anderson Lizardo <anderson.lizardo@openbossa.org> [2010-11-22 06:57:14 -0400]:
> create_singlethread_workqueue() may fail with errors such as -ENOMEM. If
> this happens, the return value is not set to a negative value and the
> module load will succeed. It will then crash on module unload because of
> a destroy_workqueue() call on a NULL pointer.
>
> Additionally, the _busy_wq workqueue is not being destroyed if any
> errors happen on l2cap_init().
>
> Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 18a802c..7980e24 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -4875,8 +4875,10 @@ static int __init l2cap_init(void)
> return err;
>
> _busy_wq = create_singlethread_workqueue("l2cap");
> - if (!_busy_wq)
> - goto error;
> + if (!_busy_wq) {
> + err = -ENOMEM;
> + goto error_busy_wq;
> + }
I prefer if you move the workqueue creation to after the
hci_register_proto block. That will make things easier.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 2/2] Fix: increment MDL and MCL reference counter in IO watchers.
From: Johan Hedberg @ 2010-11-22 17:05 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1290437712-28991-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Mon, Nov 22, 2010, Jose Antonio Santos Cadenas wrote:
> When a io_watcher is added to an MDL or an MCL channel, its reference
> should be incremented because the watcher should keep its own
> reference the the structure.
>
> Also a destroy function is added in order to decrement the reference
> once the watcher is removed.
> ---
> health/mcap.c | 28 +++++++++++++++++++---------
> 1 files changed, 19 insertions(+), 9 deletions(-)
Thanks. Pushed upstream, but I still had to tweak the summary line a
little bit (take a look at the upstream tree if you're interested).
Johan
^ permalink raw reply
* Re: [PATCH v6] Bluetooth: btwilink driver
From: Dan Carpenter @ 2010-11-22 16:46 UTC (permalink / raw)
To: pavan_savoy; +Cc: marcel, padovan, linux-bluetooth, linux-kernel
In-Reply-To: <1290424125-2717-1-git-send-email-pavan_savoy@ti.com>
On Mon, Nov 22, 2010 at 06:08:45AM -0500, pavan_savoy@ti.com wrote:
> +static int bt_ti_probe(struct platform_device *pdev)
> +{
> + static struct ti_st *hst;
> + struct hci_dev *hdev;
> + int err;
> +
> + hst = kzalloc(sizeof(struct ti_st), GFP_KERNEL);
> + if (!hst)
> + return -ENOMEM;
> +
> + /* Expose "hciX" device to user space */
> + hdev = hci_alloc_dev();
> + if (!hdev) {
> + kfree(hst);
> + return -ENOMEM;
> + }
> +
> + BT_DBG("hdev %p", hdev);
> +
> + hst->hdev = hdev;
> + hdev->bus = HCI_UART;
> + hdev->driver_data = hst;
> + hdev->open = ti_st_open;
> + hdev->close = ti_st_close;
> + hdev->flush = NULL;
> + hdev->send = ti_st_send_frame;
> + hdev->destruct = ti_st_destruct;
> + hdev->owner = THIS_MODULE;
> +
> + err = hci_register_dev(hdev);
> + if (err < 0) {
> + BT_ERR("Can't register HCI device error %d", err);
> + hci_free_dev(hdev);
Should there be a kfree(hst); here? That's how it's done in
bpa10x_probe() from drivers/bluetooth/bpa10x.c
> + return err;
> + }
> +
> + BT_DBG(" HCI device registered (hdev %p)", hdev);
^
Quite a few places have an extra space at the start.
> +
> + dev_set_drvdata(&pdev->dev, hst);
> + return err;
> +}
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 00/00] Remove deprecated items from Makefiles
From: David Miller @ 2010-11-22 16:17 UTC (permalink / raw)
To: tdent48227
Cc: marcel, padovan, linux-bluetooth, netdev, sjur.brandeland,
socketcan, urs.thuermann, socketcan-core, sage, ceph-devel,
wang840925, jlayton, kaber, pekkas, linux-kernel, netfilter-devel,
netfilter, samuel
In-Reply-To: <1290387808-2239-1-git-send-email-tdent48227@gmail.com>
From: Tracey Dent <tdent48227@gmail.com>
Date: Sun, 21 Nov 2010 20:03:11 -0500
> I changed Makefiles to use <modules>-y instead of <modules>-objs because -objs
> is deprecated and not even mentioned in Documentation/kbuild/makefiles.txt.
>
> Also, remove some if-conditional statments because I used the ccflags-$ flag
> instead of EXTRA_CFLAGS because EXTRA_CFLAGS.
All applied, thanks Tracey.
^ permalink raw reply
* [PATCH 2/2] Fix: increment MDL and MCL reference counter in IO watchers.
From: Jose Antonio Santos Cadenas @ 2010-11-22 14:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <AANLkTinQAeN8jyBmmPnw0tMWDfvOVamOU5+gBXLF-hTT@mail.gmail.com>
When a io_watcher is added to an MDL or an MCL channel, its reference
should be incremented because the watcher should keep its own
reference the the structure.
Also a destroy function is added in order to decrement the reference
once the watcher is removed.
---
health/mcap.c | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/health/mcap.c b/health/mcap.c
index 8ecdc68..81fd8df 100644
--- a/health/mcap.c
+++ b/health/mcap.c
@@ -1638,8 +1638,11 @@ static void mcap_connect_mdl_cb(GIOChannel *chan, GError *conn_err,
}
mdl->state = MDL_CONNECTED;
- mdl->wid = g_io_add_watch(mdl->dc, G_IO_ERR | G_IO_HUP | G_IO_NVAL,
- (GIOFunc) mdl_event_cb, mdl);
+ mdl->wid = g_io_add_watch_full(mdl->dc, G_PRIORITY_DEFAULT,
+ G_IO_ERR | G_IO_HUP | G_IO_NVAL,
+ (GIOFunc) mdl_event_cb,
+ mcap_mdl_ref(mdl),
+ (GDestroyNotify) mcap_mdl_unref);
cb(mdl, conn_err, user_data);
}
@@ -1774,9 +1777,11 @@ static void mcap_connect_mcl_cb(GIOChannel *chan, GError *conn_err,
mcap_mcl_ref(mcl));
}
- mcl->wid = g_io_add_watch(mcl->cc,
+ mcl->wid = g_io_add_watch_full(mcl->cc, G_PRIORITY_DEFAULT,
G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
- (GIOFunc) mcl_control_cb, mcl);
+ (GIOFunc) mcl_control_cb,
+ mcap_mcl_ref(mcl),
+ (GDestroyNotify) mcap_mcl_unref);
connect_cb(mcl, gerr, data);
}
@@ -1786,8 +1791,11 @@ static void set_mdl_properties(GIOChannel *chan, struct mcap_mdl *mdl)
mdl->state = MDL_CONNECTED;
mdl->dc = g_io_channel_ref(chan);
- mdl->wid = g_io_add_watch(mdl->dc, G_IO_ERR | G_IO_HUP | G_IO_NVAL,
- (GIOFunc) mdl_event_cb, mdl);
+ mdl->wid = g_io_add_watch_full(mdl->dc, G_PRIORITY_DEFAULT,
+ G_IO_ERR | G_IO_HUP | G_IO_NVAL,
+ (GIOFunc) mdl_event_cb,
+ mcap_mdl_ref(mdl),
+ (GDestroyNotify) mcap_mdl_unref);
mcl->state = MCL_ACTIVE;
mcl->cb->mdl_connected(mdl, mcl->cb->user_data);
@@ -1919,9 +1927,11 @@ static void set_mcl_conf(GIOChannel *chan, struct mcap_mcl *mcl)
mcl->mi->mcls = g_slist_prepend(mcl->mi->mcls,
mcap_mcl_ref(mcl));
- mcl->wid = g_io_add_watch(mcl->cc,
- G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
- (GIOFunc) mcl_control_cb, mcl);
+ mcl->wid = g_io_add_watch_full(mcl->cc, G_PRIORITY_DEFAULT,
+ G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
+ (GIOFunc) mcl_control_cb,
+ mcap_mcl_ref(mcl),
+ (GDestroyNotify) mcap_mcl_unref);
/* Callback to report new MCL */
if (reconn)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/2] Increment reference counter when a io_watcher is added
From: Jose Antonio Santos Cadenas @ 2010-11-22 14:54 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas, linux-bluetooth
In-Reply-To: <20101122144301.GC2303@jh-x301>
Hi Johan,
2010/11/22 Johan Hedberg <johan.hedberg@gmail.com>:
> Hi Jose,
>
> On Mon, Nov 22, 2010, Jose Antonio Santos Cadenas wrote:
>> Also a destroy function is added in order to avoid memory leaks
>> ---
>> health/mcap.c | 28 +++++++++++++++++++---------
>> 1 files changed, 19 insertions(+), 9 deletions(-)
>
> The patch content itself is fine but you need to fix the commit message.
> Now you have half of the info in the summary and half in the message
> body (both halves being equaly relevant). The summary line should be a
> summary of the whole patch (in this case it could be e.g. "Fix MDL
> reference counting for IO watchers") and the body should contain the
> details. So please reformulate, resend, and pay more attention to this
> kind of things in the future. Thanks :)
Sorry for for the inconvenience, I'm fixing this and sending the new
patch. I'll try be more carefully with the commit messages in the
future.
Regards
>
> Johan
>
^ permalink raw reply
* Re: [PATCH 2/2] Increment reference counter when a io_watcher is added
From: Johan Hedberg @ 2010-11-22 14:43 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1290413266-3949-1-git-send-email-santoscadenas@gmail.com>
Hi Jose,
On Mon, Nov 22, 2010, Jose Antonio Santos Cadenas wrote:
> Also a destroy function is added in order to avoid memory leaks
> ---
> health/mcap.c | 28 +++++++++++++++++++---------
> 1 files changed, 19 insertions(+), 9 deletions(-)
The patch content itself is fine but you need to fix the commit message.
Now you have half of the info in the summary and half in the message
body (both halves being equaly relevant). The summary line should be a
summary of the whole patch (in this case it could be e.g. "Fix MDL
reference counting for IO watchers") and the body should contain the
details. So please reformulate, resend, and pay more attention to this
kind of things in the future. Thanks :)
Johan
^ permalink raw reply
* Re: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Sheldon Demario @ 2010-11-22 14:38 UTC (permalink / raw)
To: Mike Tsai; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F98406D58BBA3@SC1EXMB-MBCL.global.atheros.com>
Hi Mike,
On 11/19/2010 07:49 PM, Mike Tsai wrote:
> Hi Sheldon,
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Sheldon Demario
> Sent: Friday, November 19, 2010 5:35 AM
> To: linux-bluetooth@vger.kernel.org
> Cc: Sheldon Demario
> Subject: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
>
> Sub-procedure used to read a Characteristic Value when the client
> only knows the characteristic UUID and doesn't know the handle.
> More than one handle and attribute value pair can be returned,
> it is up to the user define the handles range based on the service
> handles range.
>
> Usage example:
> $gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
> ---
> attrib/gatt.c | 15 ++++++++++++---
> attrib/gatt.h | 4 ++++
> attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/attrib/gatt.c b/attrib/gatt.c
> index 2c87daf..bca8b49 100644
> --- a/attrib/gatt.c
> +++ b/attrib/gatt.c
> @@ -74,13 +74,22 @@ guint gatt_discover_primary(GAttrib *attrib, uint16_t start, uint16_t end,
> guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
> GAttribResultFunc func, gpointer user_data)
> {
> - uint8_t pdu[ATT_DEFAULT_MTU];
> uuid_t uuid;
> - guint16 plen;
>
> sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
>
> - plen = enc_read_by_type_req(start, end,&uuid, pdu, sizeof(pdu));
> + return gatt_read_char_by_uuid(attrib, start, end,&uuid, func,
> + user_data);
> +}
> +
> +guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
> + uuid_t *uuid, GAttribResultFunc func,
> + gpointer user_data)
> +{
> + uint8_t pdu[ATT_DEFAULT_MTU];
> + guint16 plen;
> +
> + plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
> if (plen == 0)
> return 0;
>
> diff --git a/attrib/gatt.h b/attrib/gatt.h
> index 4e7d88b..1e1e628 100644
> --- a/attrib/gatt.h
> +++ b/attrib/gatt.h
> @@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
>
> guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
> GDestroyNotify notify, gpointer user_data);
> +
> +guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
> + uuid_t *uuid, GAttribResultFunc func,
> + gpointer user_data);
> diff --git a/attrib/gatttool.c b/attrib/gatttool.c
> index e961431..d0ef6d3 100644
> --- a/attrib/gatttool.c
> +++ b/attrib/gatttool.c
> @@ -398,10 +398,49 @@ done:
> g_main_loop_quit(event_loop);
> }
>
> +static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
> + guint16 plen, gpointer user_data)
> +{
> + struct att_data_list *list;
> + int i;
> +
> + if (status != 0) {
> + g_printerr("Read characteristics by UUID failed: %s\n",
> + att_ecode2str(status));
> + goto done;
> + }
> +
> + list = dec_read_by_type_resp(pdu, plen);
> + if (list == NULL)
> + goto done;
> +
> + for (i = 0; i< list->num; i++) {
> + uint8_t *value = list->data[i];
> + int j;
> +
> + g_print("handle: 0x%04x \t value: ", att_get_u16(value));
> + value += 2;
> + for (j = 0; j< list->len - 2; j++, value++)
> + g_print("%02x ", *value);
> + g_print("\n");
> + }
> +
> + att_data_list_free(list);
> +
> +done:
> + g_main_loop_quit(event_loop);
> +}
> +
> [MTsai] in your call back function here, you assume that "read_by_type_request" operation has completed. In the case of example with uuid=0x2a00 (device name), this is probably true. However, if there are multiple characteristics with same UUID within the database, then server probably has not sent all the characteristic value back yet, shall you check to see if the reading is really completed (comparing the handle), otherwise, issue another read_by_type_request with starting handle = attribute handle+1?
You are right. According to the spec it is necessary to iterate until
the server replies<<Attribute Not Found>>,
multiple characteristics can be split due the MTU value. However is
this the behavior that we need? gatttool is only a command line tool
implemented to allow the user to test some scenario that it is not
possible to test using a "real" client.
The user can issue another request using the gatttool and send the
Start Handle set to one greater that the last Attribute Handle.
I gonna implement this feature just keep the same approach of discover
all primary services in the gatttool.
> static gboolean characteristics_read(gpointer user_data)
> {
> GAttrib *attrib = user_data;
>
> + if (opt_uuid != NULL) {
> + gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
> + char_read_by_uuid_cb, attrib);
> + return FALSE;
> + }
> +
> if (opt_handle<= 0) {
> g_printerr("A valid handle is required\n");
> g_main_loop_quit(event_loop);
^ permalink raw reply
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