On Thu, 2016-11-10 at 22:30 +0100, Tobias Herzog wrote: > Hi, > > I'm trying to build an usb device conforming to the CDC ACM device > class. The device uses an interrupt IN endpoint with a max packet size > of 8 bytes. > I tried to send a SERIAL_STATE notification to the host (to report > parity errors, etc.) and noticed, that it is not handled as I would > expect: > > Because I have to transmit the notification in two consecutive packets > due to the limited packe size (SERIAL_STATE notification consists of an > 8 byte header + 2 byte data), acm_ctrl_irq is called twice, too. So the > notification is not reassembled before processing in acm_ctrl_irq. Of > course acm_ctrl_irq only handles "garbage" in this cases because both > recieved packages are to short. That case was not considered in the spec or in the driver. > Obviously the max packet size of the interrup IN endpoint needs to be > equal (or greater) to the size of the largest notification the CDC > device may transmit, to work with the cdc_acm module. Yes > Question: > Is this just a (probably quite realistic) assumption made in the > current kernel code, or is this constraint defined in the usb > specification? The assumption is made in the driver. Transmitting the package in two steps like you do, is an obvious method to deal with the constraint, but the spec does not mention it. > I'm new to the usb stuff and am not sure if i missed something. > Additionally I am confused, because Atmel provides some documentation > how to build a CDC ACM device [1], where the fragmented transmission of > notifications is explicitely stated as one possible implementation. If they mention it, it may be more widely used. I'd welcome a patch for the ACM driver. Would you provide one? Regards Oliver -- 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
