plunky@rya-online.net said:
> ubt provides an event buffer with the size that is the maximum
> Bluetooth event packet size and let the usb stack fill it in

This is definitely correct -- the USB spec (ch. 5.7.3) explicitely
mentions the case that an interrupt transfer (the term "transfer"
is used inconsistently) involves multiple transactions where all
but the last have the maximum payload size.

> what happens with this patch for instance when doing a 'btconfig -vvvv' ?
> eg, the Read_Local_Name response packet in particular is I think 256 bytes..

Yep, the device name gets truncated.
Using the packet size of 16 at the driver request level is
certainly not right. Reassembly should be done by the USB host
adapter layer. Remains the question why transfers which consist
of one USB packet get through while larger ones don't.

> I would say though, that since the uhci code does automatically catenate
> USB packets into a single transfer (the bluetooth packet), the ehci code
> should do that properly also..

As I understand it, the EHCI hardware is supposed to do that automatically.
See the description of the "queue head" and the "queue element transfer
descriptor" (ch 3.6/3.5) in the EHCI spec.
It might be that the desciptors are not filled in correctly, or that
there is a bug in interrupt handling which makes that the response
is ignored, or something with the data toggle handshake, or with
the translation...

best regards
Matthias