> + /* > + * Since the driver is reverse-engineered, we don't know how to > + * ask the device if bytes were actually transmitted. So, when > + * writes return and our URBs have completed, the bits are still > + * being sent. When we close and reopen, one data byte is lost. > + * Nothing to it but sleep a little bit while transmit drains. > + * RH bz#170490. > + */ > + msleep(2); NAK but only to the implementation - if this is dependant upon the amount of data then we should compute a delay based upon the queue size. Quite a few drivers have a need for this and it's part of the standard port close handling as a result. Simply set port->port.drain_delay = 256; /* good first guess */ and the rest should happen automatically and correctly sequenced with the carrier and flow control signals. A lot of hardware just delays so it's entirely possible that there isn't a magic transmit drain in any given device. Alan -- 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
