Hi Lizardo,
On Fri, Mar 25, 2011, Anderson Lizardo wrote:
> > On Fri, Mar 25, 2011, Anderson Lizardo wrote:
> >> > +static u16 get_uuid16(u8 *uuid128)
> >> > +{
> >> > + Â Â Â u8 *b = bluetooth_base_uuid;
> >> > + Â Â Â u32 val;
> >> > + Â Â Â int i;
> >> > +
> >> > + Â Â Â for (i = 4; i < 16; i++) {
> >> > + Â Â Â Â Â Â Â if (b[i] != uuid128[i])
> >> > + Â Â Â Â Â Â Â Â Â Â Â return 0;
> >>
> >> Don't you need to check bytes 0 and 1 as well, i.e. only bytes 2 and 3
> >> are changed?
> >
> > The first four bytes can have any value for Bluetooth UUIDs. The purpose
> > of this part of the function is to determine whether it's a Bluetooth
> > UUID or not (i.e. derived from the Bluetooth base UUID), so the four
> > first bytes don't matter.
>
> At least for UUIDs used in attribute types I see this on the spec (page 1835):
>
> "Or, to put it more simply, the 16-bit Attribute UUID replaces the xâs
> in the follow-
> ing:
> 0000xxxx-0000-1000-8000-00805F9B34FB"
>
> I.e. , only third and fourth bytes being part of 16-bit UUID.
That's correct, and we're not contradicting each other here. The
function simply in the first stage doesn't care if it's a 32 or 16 bit
Bluetooth UUID and only after that it does the > 0xffff comparison.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
