libhci update

[Iain Hibbert]

On Thu, 14 May 2009, Maksim Yevmenkin wrote:

> that is for 'forceful' role switch when we are accepting connection.
> basically always try to become master on any connection (or not).

Mm, I didn't put that into netbsd (yet) so it can remain 0 for now,
thanks.

> >> > 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.
>
> sorry, are we talking about bt_devrecv() in isolation, or about
> bt_devinquiry() usage of bt_devrecv().
>
> in other words, are you saying we should fix bt_devinquiry() and make
> sure that is decreases timeout with every call to bt_devrecv()?

yes, sorry - what bt_devrecv() does in isolation is fine, it is
bt_devinquiry() that should manage a cumulative target for timeout.

(btw 'close call' in quote above is 'near miss' not 'close() call' :)

> yes, inquiry is weird (from baseband point of view) procedure. device
> basically has to blast on the range of frequencies and wait for
> someone to respond. technically, nothing prevents device from doing
> other rf activity, but some devices choose not to do it.

I haven't looked but I think from skimming their list that latest linux
code (not sure if in kernel or bluetoothd) sets the device into inquiry
state and manages the connections to avoid errors in that situation. I
thought about that for netbsd but didn't get far - it also would cover
things like pausing encryption to make role switches and suchlike which
was causing me a trouble when I tried to make a MASTER mode work.

iain