libhci update

[Iain Hibbert]

On Thu, 14 May 2009, Maksim Yevmenkin wrote:

> Iain,
>
> >> thanks for the review. i committed it to -head.
> >
> > Hi Max, I'm in progress of translating for NetBSD and in bt_devinquiry() I
> > see
> >
> >        if (ii == NULL) {
> >                errno = EINVAL;
> >                return (-1);
> >        }
> >
> > but I think this test might be bogus? manpage implies that the caller
> > provides a buffer but we allocate one..
>
> no, the test is correct. yes, we allocate buffer internally, but we
> need to return pointer to the buffer back to the caller. so, ii is
> basically ii is struct bt_devinquiry **. perhaps language in the man
> page is not clear enough?

Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a
spelling mistake earlier but I didn't note it :), will examine it in
detail later. I'm trying to think of another function that does similar to
copy the language from, perhaps asprintf()?

btw do you know what devinfo->role_switch_info might contain?  I have
link_policy_info which presumably contains the following flags

/* Link policy settings */
#define HCI_LINK_POLICY_DISABLE_ALL_LM_MODES	0x0000
#define HCI_LINK_POLICY_ENABLE_ROLE_SWITCH	0x0001 /* Master/Slave switch */
#define HCI_LINK_POLICY_ENABLE_HOLD_MODE	0x0002
#define HCI_LINK_POLICY_ENABLE_SNIFF_MODE	0x0004
#define HCI_LINK_POLICY_ENABLE_PARK_MODE	0x0008
/* 0x0010 - 0x8000 - reserved for future use */

but I'm not sure what to put in role_switch_info? (for now, 0 :)

> > also, I'm not sure that the timeout is handled right; the bt_devrecv()
> > uses the complete timeout each time but the time endpoint might need to be
> > calculated so that time-to-end can be used?
>
> well, yes. bt_devrecv() was envisioned as "one-shot" call. the only
> case, imo, where it can restart internally with the same timeout is
> when select is interrupted by a signal.

I think the timeout should probably act the same way as in bt_devreq(),
but I thought there could be close calls at the end because of the integer
arithmetic.

> > Also I'm wondering what to do in the case bt_devrecv() does actually time
> > out - what can it mean and should we [attempt to] cancel the inquiry?
>
> ahh, but in case of bt_devinquiry() it probably does not matter that
> much because inquiry itself is limited by the "length" parameter. so
> we have to receive something back from the device. i was thinking to
> pass -1 as timeout to bt_devrecv() in this particular case, but
> decided not to do it (try harder to exit the bt_devinquiry()).

mm, -1 is tempting but I think its better to error timeout even if the
device is left in a weird state. At least the user won't be left waiting..

I'll continue to work on it because a successful exit must wait until the
device has exited inquiry mode. (I noticed that you can't do things like
get-remote-name when still in inquiry mode, at least on some devices)

iain