All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] bccmd reading clock
Date: Sun, 03 Jul 2005 18:56:16 +0200	[thread overview]
Message-ID: <1120409776.10273.71.camel@pegasus> (raw)
In-Reply-To: <20050703163538.1E47C3FB@arbetsmyra.dyndns.org>

Hi Ronny,

> > actually I added the clock reading support by copying the uint32
> > reading command. Using the complex command needs a little bit more
> > testing and of course audit. The CSR BCCMD can be quite picky if you
> > do something wrong. I also added support for uint32 and BT_CLOCK to
> > hcidump.
> 
> Ok. Nice, but how can we "test" the complex command if we don't use it? 
> I agree we need to be careful yes, but BCCMD works in ram only, right? 
> If something goes wrong one can just do a cold reset to restore 
> settings.

it is not about the settings. The bccmd tool must be usable all the time
without crashing the device at runtime. Feel free to send new patches
against the current CVS. I will see if I get some time to review and of
course test them.

> > The UART config is used via BCCMD for temporary changes and via the
> > PSKEY for permanent changes. I didn't added it, because I don't like
> > mixing patches. One patch per feature.
> 
> I understand. Besides the UART feature I've also added preliminary 
> support for these additional commands:
> 	- Read RSSI
> 	- Read/write BER threshold
> 	- Read/write max tx power
> 	- Read/write default tx power
> And also made a find_conn_handle() function to automatically get the 
> ACL connection handle and pass it on to all the BCCMDs who needs it 
> (most of them, including your "keylen" function). User can then use the 
> commands simply with a <bdaddr> on the commandline instead of the 
> harder to find handle. Should I send you patches for these too? Perhaps 
> separated in smal chunks?

Send small chunks and step by step. It is then easier for me to review
them and apply them. This is also better for the revision history.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

      reply	other threads:[~2005-07-03 16:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-27 22:37 [Bluez-devel] bccmd reading clock Ronny L Nilsson
2005-06-28 15:42 ` Marcel Holtmann
2005-06-29  8:26   ` Ronny L Nilsson
2005-07-01  8:43     ` Ronny L Nilsson
2005-07-03 10:16     ` Marcel Holtmann
2005-07-03 16:33       ` Ronny L Nilsson
2005-07-03 16:56         ` Marcel Holtmann [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=1120409776.10273.71.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /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.