* Re: [Bluez-devel] hciconfig
2003-10-09 0:58 ` [Bluez-devel] hciconfig Max Krasnyansky
@ 2003-10-09 12:00 ` Steven Singer
2003-10-09 17:25 ` Max Krasnyansky
0 siblings, 1 reply; 3+ messages in thread
From: Steven Singer @ 2003-10-09 12:00 UTC (permalink / raw)
To: Max Krasnyansky; +Cc: Christian Eiselt, bluez Dev
Max Krasnyansky wrote:
> In older HCI implementation HCI_Reset used to reset USB transport even
> though spec clearly states that it shouldn't. This may cases all sorts
> of problems. Looks like you got one of those dongle with buggy HCI
> implementation.
I'd like to pick you up on the words "clearly" and "buggy". This is an
example of how the Bluetooth spec has been tightened to avoid ambiguity.
The Bluetooth 1.1 spec now reads:
The Reset command will reset the Host Controller and the Link Manager.
The reset command should not affect the used HCI transport layer since
the HCI transport layers have reset mechanisms of their own.
Which is fairly clear. However, previous versions of the spec (up to
and including 1.0B) used to read:
The Reset command will reset the Bluetooth Host Controller, Link
Manager, and the radio module.
There are two differences. The 1.1 spec contains a clarification that
the transport "should not" be reset. In contrast, not only does the
earlier spec not contain this line, it also states that the radio
module should be reset.
Reading the earlier spec on its own it can easily be read to mean that
the entire Bluetooth dongle is reset. After all, when we normally talk
about the "host controller" we normally refer to the entire Bluetooth
dongle. For example, if we're talking on this mailing list about the
USB interface I might say "the host controller advertises three USB
endpoints" (or whatever), I would not say "the USB host transport
entity on the host controller advertises three USB endpoints".
I think a device that fully resets on receiving an HCI_Reset is
following a legitimate interpretation of the 1.0B spec.
However, this is not what the spec author intended. Hence the
tightening.
Note that the 1.1 spec is not completely unambiguous. It says that the
reset command "should" not affect the host transport. Not that it
"shall" or "must" not. A pedant might argue that the 1.1 spec still
allows resetting of the host transport. Although this is a possible
interpretation, I do not believe that it is a reasonable
interpretation.
One of the changes in the Bluetooth 1.2 spec (which I can't quote
here as it's not released yet) is that the wording has been
tightened to use IEEE language throughout the entire spec (a mammoth
job). Consequently, the word "should" shouldn't appear anywhere in
the spec. It should all be "shall" or "may".
So, after that historical diversion, some more concrete advice. Early
CSR dongles (up to, and including version 11 firmware) followed the
interpretation of the earlier spec that allowed HCI_Reset to reset the
host transport. All modern CSR devices (version 12 firmware and later)
do not reset the transport. If you have one of our old devices you have
two options:
1) The proper solution: upgrade your CSR firmware to a more recent
version (generally a good thing).
2) The quick hack: set the PS key PSKEY_HCI_RESET_STUB (0x00F1)
to 1. This causes the HCI_Reset command to be a no-operation.
We still emit the command_complete but we do not reset any
active links. This hack is a useful workround if your host
stack always issues an HCI_Reset as the first command to any
new device it finds.
Nowadays I would not recommend option 2, I would recommend only
option 1.
If you're using a Bluetooth dongle from another manufacturer, then
you'll need to contact them to find out what to do.
- Steven
--
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply [flat|nested] 3+ messages in thread