On Mon, 8 Aug 2011, Sarah Sharp wrote: > > 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? Does the driver need to do anything at all? As far as I can tell, bursting is controlled by the NumP field in the ACK transaction packet. This value is set automatically by the UDC driver or hardware; the gadget driver has nothing to do with it. Therefore the mass-storage gadget drivers shouldn't need any changes to support bursting. Alan Stern -- 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
