All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gix <bgix@codeaurora.org>
To: Anderson Lizardo <anderson.lizardo@openbossa.org>
Cc: linux-bluetooth@vger.kernel.org, johan.hedberg@nokia.com,
	padovan@profusion.mobi
Subject: Re: [PATCH 3/3] Add gatttool enhancements for UPF
Date: Wed, 16 Feb 2011 07:53:05 -0800	[thread overview]
Message-ID: <4D5BF2E1.6070102@codeaurora.org> (raw)
In-Reply-To: <AANLkTi=dwj0Bc_509JW8-HfkYBfzmfSzR0GJxNqoLXye@mail.gmail.com>

Hi Anderson,

The modifications to gatttool were largely organic in nature and on the 
fly responses to the needs of my UPF testing. Also, it is of course just 
a test tool.

More inline.

On 2/14/2011 1:41 PM, Anderson Lizardo wrote:
> Hi Brian,
>
> On Wed, Feb 16, 2011 at 6:18 PM, Brian Gix<bgix@codeaurora.org>  wrote:
>> @@ -90,9 +91,9 @@ static GIOChannel *do_connect(gboolean le)
>>
>>         /* This check is required because currently setsockopt() returns no
>>          * errors for MTU values smaller than the allowed minimum. */
>> -       if (opt_mtu != 0&&  opt_mtu<  ATT_MIN_MTU_L2CAP) {
>> +       if (opt_mtu != 0&&  opt_mtu<  23) {
>>                 g_printerr("MTU cannot be smaller than %d\n",
>> -                                                       ATT_MIN_MTU_L2CAP);
>> +                                                       23);
>>                 return NULL;
>>         }
>
> The changes above seem unrelated to this patch.

The code was incorrect in that it limited it to 48 instead of 23. 
However, I should have used the ATT_MIN_MTU_LE define. This will be fixed.

>
>>
>> @@ -277,6 +278,14 @@ static gboolean characteristics(gpointer user_data)
>>         return FALSE;
>>   }
>>
>> +static void char_write_cb(guint8 status, const guint8 *pdu, guint16 plen,
>> +                                                       gpointer user_data)
>> +{
>> +       if (plen == 1)
>> +               g_print("Attrib Write Succeeded\n");
>> +       else
>> +               g_printerr("Attrib Write failed: %s\n", att_ecode2str(status));
>
> Why not check by the status instead of plen ?

During testing, it was apparent that status did not contain Zero. This 
may be due to there being no status octet in the WRITE_RSP packet. I 
didn't have time to trace this back into the gatt code, but will do so now.

>
> Also, I'd suggest "Characteristic write" instead of "Attrib Write".
>
>> +}
>>   static void char_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
>>                                                         gpointer user_data)
>>   {
>> @@ -427,7 +436,40 @@ static gboolean characteristics_write(gpointer user_data)
>>                 goto error;
>>         }
>>
>> +       gatt_write_char(attrib, opt_handle, value, len, char_write_cb, value);
>> +       gatt_read_char(attrib, opt_handle, char_read_cb, attrib);
>
> Why both read and write ?

I needed to do this to confirm that the write actually succeeded within 
the bounds of the testing, which included not dropping the connection 
between the two procedures. This will not be needed for the forthcoming 
interactive gatttool, but that was not available for UPF.  As it is, I 
would argue that this is more useful in a test tool than superfluous.

>
>> +
>> +       return FALSE;
>> +
>> +error:
>> +       g_main_loop_quit(event_loop);
>> +       return FALSE;
>> +}
>> +
>> +static gboolean characteristics_cmd(gpointer user_data)
>> +{
>> +       GAttrib *attrib = user_data;
>> +       uint8_t *value;
>> +       size_t len;
>> +
>> +       if (opt_handle<= 0) {
>> +               g_printerr("A valid handle is required\n");
>> +               goto error;
>> +       }
>> +
>> +       if (opt_value == NULL || opt_value[0] == '\0') {
>> +               g_printerr("A value is required\n");
>> +               goto error;
>> +       }
>> +
>> +       len = attr_data_from_string(opt_value,&value);
>> +       if (len == 0) {
>> +               g_printerr("Invalid value\n");
>> +               goto error;
>> +       }
>> +
>>         gatt_write_cmd(attrib, opt_handle, value, len, mainloop_quit, value);
>> +       gatt_read_char(attrib, opt_handle, char_read_cb, attrib);
>
> Same question here.

Same response here.

>
>>
>>         return FALSE;
>>
>> @@ -531,6 +573,8 @@ static GOptionEntry gatt_options[] = {
>>                 "Characteristics Value/Descriptor Read", NULL },
>>         { "char-write", 0, 0, G_OPTION_ARG_NONE,&opt_char_write,
>>                 "Characteristics Value Write", NULL },
>> +       { "char-cmd", 0, 0, G_OPTION_ARG_NONE,&opt_char_cmd,
>> +               "Characteristics Value Cmd", NULL },
>
> Suggestion:  "Characteristic Value write using Write Command" (or
> something similar).
>
>>         { "char-desc", 0, 0, G_OPTION_ARG_NONE,&opt_char_desc,
>>                 "Characteristics Descriptor Discovery", NULL },
>>         { "listen", 0, 0, G_OPTION_ARG_NONE,&opt_listen,
>> @@ -561,7 +605,7 @@ int main(int argc, char *argv[])
>>         GError *gerr = NULL;
>>         GAttrib *attrib;
>>         GIOChannel *chan;
>> -       GSourceFunc callback;
>> +       GSourceFunc callback = NULL;
>>
>>         context = g_option_context_new(NULL);
>>         g_option_context_add_main_entries(context, options, NULL);
>> @@ -602,9 +646,11 @@ int main(int argc, char *argv[])
>>                 callback = characteristics_read;
>>         else if (opt_char_write)
>>                 callback = characteristics_write;
>> +       else if (opt_char_cmd)
>> +               callback = characteristics_cmd;
>>         else if (opt_char_desc)
>>                 callback = characteristics_desc;
>> -       else {
>> +       else if (!opt_listen) {
>>                 gchar *help = g_option_context_get_help(context, TRUE, NULL);
>>                 g_print("%s\n", help);
>>                 g_free(help);
>> @@ -625,7 +671,8 @@ int main(int argc, char *argv[])
>>         if (opt_listen)
>>                 g_idle_add(listen_start, attrib);
>>
>> -       g_idle_add(callback, attrib);
>> +       if (callback)
>> +               g_idle_add(callback, attrib);
>>
>>         g_main_loop_run(event_loop);
>
> Regards,


-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

  reply	other threads:[~2011-02-16 15:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-16 21:17 [PATCH 0/3] Modifications composed during UPF38 Brian Gix
2011-02-16 21:17 ` [PATCH 1/3] Fixed def of ATT_UUID per BT Assigned Numbers Brian Gix
2011-02-15 17:08   ` Johan Hedberg
2011-02-16 21:18 ` [PATCH 2/3] Add SDP registration of Primary GATT services Brian Gix
2011-02-14 21:53   ` Anderson Lizardo
2011-02-16 16:26     ` Brian Gix
2011-02-16 17:00       ` Anderson Lizardo
2011-02-16 21:18 ` [PATCH 3/3] Add gatttool enhancements for UPF Brian Gix
2011-02-14 21:41   ` Anderson Lizardo
2011-02-16 15:53     ` Brian Gix [this message]
2011-02-16 16:38       ` Anderson Lizardo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D5BF2E1.6070102@codeaurora.org \
    --to=bgix@codeaurora.org \
    --cc=anderson.lizardo@openbossa.org \
    --cc=johan.hedberg@nokia.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=padovan@profusion.mobi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.