All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzu-Jung Lee <roylee17@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 1/3] tools: Fix usage for hciattach command
Date: Fri, 19 Sep 2014 10:41:56 -0700	[thread overview]
Message-ID: <CAEvN+1it1XmqUSv2dCuM_Dd4nroN+49y1EBSbCF_ppR0=iMh0g@mail.gmail.com> (raw)
In-Reply-To: <CAEvN+1h=p3Jy0sH+8=i1z=DHF7_5OHpww2gHWwTOuTCfUpSESw@mail.gmail.com>

Hi Luiz,

Any comment for the patch 2/3 ?

Thanks.
Roy

On Mon, Sep 15, 2014 at 11:23 AM, Tzu-Jung Lee <roylee17@gmail.com> wrote:
> Hi Luiz,
>
> On Mon, Sep 15, 2014 at 12:00 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi,
>>
>> On Tue, Sep 9, 2014 at 12:21 AM,  <roylee17@gmail.com> wrote:
>>> From: Tzu-Jung Lee <roylee17@gmail.com>
>>>
>>> ---
>>>  tools/hciattach.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/hciattach.c b/tools/hciattach.c
>>> index 1904ac5..542b5b3 100644
>>> --- a/tools/hciattach.c
>>> +++ b/tools/hciattach.c
>>> @@ -1276,7 +1276,7 @@ static void usage(void)
>>>  {
>>>         printf("hciattach - HCI UART driver initialization utility\n");
>>>         printf("Usage:\n");
>>> -       printf("\thciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> <type | id> [speed] [flow|noflow] [bdaddr]\n");
>>> +       printf("\thciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty> <type | id> [speed] [flow|noflow] [sleep|nosleep] [bdaddr]\n");
>>>         printf("\thciattach -l\n");
>>>  }
>>>
>>> --
>>> 2.0.4
>>
>> It doesn't look like you are doing anything with sleep|nosleep here,
>> also you should probably a add more information regarding what it is
>> fixing.
>>
>
> I probably should have separated these 3 patches to 2 different sets
> though they are all trivial fixes.
>
>
> The first one attempts to reveal the missing [speed | nospeed] to the user:
>
> Currently, the argument parsing code in the hciattach.c expect very
> specific order of the arguments:
>
>     hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed]
> <tty> <type | id> [speed] [flow|noflow] [bdaddr]
>
> For example, if an user would like to specify the BDADDR, none of the
> following works:
>
>     hciattach TTY any BDADDR
>     hciattach TTY any SPEED BDADDR
>     hciattach TTY any SPEED NOFLOW BDADDR
>
> The user has to put the BDADDR exactly in the 4th argument after <type
> | id>, ex:
>
>     hciattach TTY any SPEED NOFLOW NOSLEEP BDADDR
>
> And this is impossible to figure out without looking at the source code.
> The patch only helps a little (hope so) by revealing the missing
> argument to the user.
>
>     hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed]
> <tty> <type | id> [speed] [flow|noflow] [sleep|nosleep] [bdaddr]
>
> Though I do agree the information is still too little, and we probably
> should rewrite the argument parsing code to remove the enforcement of
> order.
> Otherwise, the precise usage syntax for the current logic should be:
>
>    hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty>
> <type | id> [speed]
>    hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty>
> <type | id> [speed flow|noflow]
>    hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty>
> <type | id> [speed flow|noflow] sleep|nosleep]
>    hciattach [-n] [-p] [-b] [-r] [-t timeout] [-s initial_speed] <tty>
> <type | id> [speed flow|noflow sleep|nosleep bdaddr]
>
> Even though, user still need to figure out what suppose to be put in
> the flow/sleep if he only wants to change the bdaddr without changing
> other default settings.
>
>
> The second patch speed up the firmware loading speed by raising the
> UART baudrate before (and after) loading firmware.
> This helps our project reduce the hciattach from 7+ seconds, to 750 ms.
> The tricky part for the controller is that it drops the UART back to
> 115200 after firmware loading.
> So we still need to update the baudrate again after firmware is loaded.
>
> Thanks.
> Roy
>
>> --
>> Luiz Augusto von Dentz

      reply	other threads:[~2014-09-19 17:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 21:21 [PATCH 1/3] tools: Fix usage for hciattach command roylee17
2014-09-08 21:21 ` [PATCH 2/3] tools: Use specified uart speed to load firmware for bcm43xx roylee17
2014-09-08 21:22 ` [PATCH 3/3] tools: Fix download mode delay " roylee17
2014-09-15  7:00 ` [PATCH 1/3] tools: Fix usage for hciattach command Luiz Augusto von Dentz
2014-09-15 18:23   ` Tzu-Jung Lee
2014-09-19 17:41     ` Tzu-Jung Lee [this message]

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='CAEvN+1it1XmqUSv2dCuM_Dd4nroN+49y1EBSbCF_ppR0=iMh0g@mail.gmail.com' \
    --to=roylee17@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /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.