libhci update

[Iain Hibbert]

On Thu, 16 Apr 2009, Iain Hibbert wrote:

> +int
> +bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old)
>
> And finally, the HCI filter is slightly different in NetBSD (I provided
> independent PKT and EVT filters each of 256 bits) and I'm going to think
> about that..

Ok, I'm not objecting in priniciple to coupling the two filters together
but I think that bt_devfilter should be opaque enough that the API does
not depend about its internal structure. Ie, requiring the caller to
subtract 1 and manage the bitwise manipulation

+	f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_COMPL - 1));
+	f.event_mask |= (1 << (NG_HCI_EVENT_INQUIRY_RESULT - 1));

is too specific and makes the callers somewhat messy. Can we provide some
kind of accessor functions to do that?  I include below what I used in
NetBSD for an example..

Also, at least for events, the full 256 bits is required because there are
events such as 0xfe (BT Logo) and 0xff (Vendor) that may currently be
returned and the highest value (in 2.1 spec) is 0x3d, dangerously close to
the 64 bit limit. Although its not likely that there will be many packet
types added, it could be that some manufacturers would introduce custom
packet types with similarly high end values.. (eg for private device
configuration?)

regards,
iain

/*
 * HCI socket filter and get/set routines
 *
 * for ease of use, we filter 256 possible events/packets
 */
struct hci_filter {
	uint32_t	mask[8];	/* 256 bits */
};

static __inline void
hci_filter_set(uint8_t bit, struct hci_filter *filter)
{
	uint8_t off = bit - 1;

	off >>= 5;
	filter->mask[off] |= (1 << ((bit - 1) & 0x1f));
}

static __inline void
hci_filter_clr(uint8_t bit, struct hci_filter *filter)
{
	uint8_t off = bit - 1;

	off >>= 5;
	filter->mask[off] &= ~(1 << ((bit - 1) & 0x1f));
}

static __inline int
hci_filter_test(uint8_t bit, struct hci_filter *filter)
{
	uint8_t off = bit - 1;

	off >>= 5;
	return (filter->mask[off] & (1 << ((bit - 1) & 0x1f)));
}