RE: Linux 2.6.39

[Cufi, Carles]

 (Snipping...)
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@xxxxxxxxxxxxx>
wrote:
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
...
>> > Read Local Version Information (0x04|0x0001) plen 0
>> > > HCI Event: Command Complete (0x0e) plen 12
>> >     Read Local Version Information (0x04|0x0001) ncmd 1
>> >     status 0x00
>> >     HCI Version: 1.1 (0x1) HCI Revision: 0x20d
*************************
>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
*************************
>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set 
>> > Event Mask (0x03|0x0001) plen 8
>> >     Mask: 0xfffffbff00000000
*************************
>> > > HCI Event: Command Complete (0x0e) plen 4
>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >     status 0x12
>> >     Error: Invalid HCI Command Parameters
>
>Set Event Mask has been in the Bluetooth Spec since day 1, so it must 
>be
>the bitmask, which has been extended with each new spec release to cover newly >added events. Looking at the latest spec, and judging >by the year your chipset was released in (it probably is a 1.1 compliant chipset) I believe that >0x000000008FFFFFFF is the highest >event mask it would support (up until and including Page Scan Repetition Mode Change Event), but since I don't have the >old 1.1 spec >around I may be one or two bits off.

>The device appears to have identified itself as CSR firmware using Bluetooth version 1.1.
>I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it says
>0x0000000100000000
>To                                          Reserved for future use
>0x8000000000000000
>0x00000000FFFFFFFF	Default (All events enabled)
>The mask above looks ok (no undefined bits), but are they supposed to be displayed in that order? (IOW, are the bytes in correct >order?)

The HCI spec lists this as a 64-bit number but it must be sent in Little Endian to the controller, hence the reverse order in Ville Tervo's patch earlier in the email thread. 

Carles

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/