On Thu, Aug 04, 2011 at 10:13:43AM -0400, Alan Stern wrote:
> On Thu, 4 Aug 2011, Felipe Balbi wrote:
>
> > > > > +static struct usb_ss_ep_comp_descriptor fsg_ss_bulk_in_comp_desc = {
> > > > > + .bLength = sizeof(fsg_ss_bulk_in_comp_desc),
> > > > > + .bDescriptorType = USB_DT_SS_ENDPOINT_COMP,
> > > >
> > > > Where does the bMaxBurst field get set up?
> > >
> > > well, it doesn't. It's not mandatory, right, to use Bursts here and,
> > > while it would be really nice to use it for command queueing, we don't
> >
> > and here I confused bursts with streams ;-) sorry.
>
> Yeah, they're not the same thing.
>
> > > know how windows will behave with a e.g. USB3-capable Bulk-only MSC
> > > device.
> >
> > still optional, though, and we don't know how Windows would cope with
> > this. Does it make sense to add some value here ?
>
> I don't know. My question above really was just a question, not a
> criticism of the patch.
>
> Bursting is handled almost entirely by the hardware, so in theory
> Windows shouldn't have any trouble coping with it. For the same
> reason, gadget drivers shouldn't have to worry about it -- the UDC
> driver should be responsible for setting the bMaxBurst fields.
There's no official Windows driver, so this answer is a bit moot, but I
have seen the NEC/Rensas Windows driver use bursts with mass storage
devices.
I think it makes sense to set a non-zero burst size in the MSC gadget
driver if it can handle it. The driver will have to handle that number
of packets being sent without receiving an ACK from the host (in the
case of bulk IN), or being able to receive that number of packets
without needing to send an ACK between packets (in the case of bulk
OUT). Can the driver currently handle that?
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
