[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] Re: Big endian issues for ARM patch



Matthias Fuchs wrote:

>
> typedef struct cmd_pkt {
>         u32 type:8;
> #if (__BYTE_ORDER == __LITTLE_ENDIAN)
>         u32 ocf:10;
>         u32 ogf:6;
> #else
>         u32 ogf:6;
>         u32 ocf:10;
> #endif
>         u32 len:8;
>         u8 data[256];
> } cmd_pkt;
>
> The send_cmd funtion should be changed in this way:
>
> s32
> send_cmd(u8 *cmd, u8 len)
> {
> #if (__BYTE_ORDER == __BIG_ENDIAN)
>         u8 tmp;
>         tmp = cmd[1];
>         cmd[1] = cmd[2];
>         cmd[2] = tmp;
> #endif
>         D_CMD("send_cmd : cmd_num %d\n", hci_ctrl.hc_buf.cmd_num);
>

This much looks good. Another thing to check in HCI is anyplace you use
memcpy to put multiple bytes into a packet before sending (there are 3 or 4
places). If the data being placed is byte-oriented data (like the BD addr
and the link keys) then this should be OK. But if you're memcpy'ing 16 |
32-bit values this won't work. Another place to watch for problems is on
receiving, when interpreting 16 & 32-bit fields in the byte stream. But I
think the existing CHAR2INT* macros handle this.

> Together with Gordon's patch, I had nmo problems running the stack on a
> PowerPC CPU.
>
> Any better idea ?
>
> Gordon, you talked about some big endian fixes. What have you changed ?
> Is it possible that you do not see the HCI problem when you are running
> the HCI emulator (I did not really look into that code) ?
>

My HCI changes were accidentally lost when I merged in the 11/15 code. Not
sure how. My patch against the 10/31 drop probably had them. I didn't
notice they were missing from the 11/15 patch until after I has posted it
(during which time I didn't have my big-endian hardware to verify
anything).

Quite a few changes were made to RFCOMM, and some to L2CAP.

>
> It would ne nice to get some comments, so that I can send a useful patch
> or perhaps Gordon (?) will include it in his patch (..to reduce the
> number of patches).
>

I'm attaching a patch for what I currently have against hci.c (with my
endian fixes the best I can reproduce them). Note that I haven't had a
chance to test this for big-endian (still no h/w...). I don't recommend
applying this patch, but use it for a reference.

I think you're redefinition of cmd_pkt is a better solution than my
put_hci_opcode macro, and is consistent with the changes in rfcomm.c. But
take note of where I replaced memcpy. You can ignore the WASTE_SPACE stuff
(an experiment with reducing the size for embedded systems).

Incidentally, do you intend to merge these into the main kernel tree so
that people don't have to keep applying (and maintaining ;)) patches? And
I'll take this opportunity to bug you again about CVS... ;)

--Gordon

p.gz