On 15.06.2012 23:33, Greg KH wrote: > On Wed, Jun 13, 2012 at 12:54:45PM +0200, Daniel Mack wrote: >> The hidg function driver currently handles its SET_REPORT calls via EP0. >> This is the implicit behaviour when no OUT interrupt endpoint is >> configured and generally works fine. >> >> The problem is that due to EP0's role in the gadget framework, we cannot >> hold back packets and control traffic flow to sync it to the char device, >> and hence there's a high risk of loosing packets with this >> implementation. >> >> This patch adds an OUT interrupt endpoint to the interface and queues a >> fix number of request to catch SET_REPORT events. According to the >> specs, host drivers should always use the dedicated OUT endpoint when >> present. >> >> The char device's read implementation was rewritten to retrieve data >> from the list of completed output requests. > > That's a lot of different things all being done at once, can you please > break this up into the different logical changes you made here and send > this as a series of patches so we can better review them? Hmm, I thought so too, but the thing is that breaking this patch into smaller, bisectable parts seems in fact impossible. What it does after all is to move away from the approach that there is only one active packet buffer to be filled, to an implementation where there are many packets in the flight. This implies some sort of queue management, and this has to be taken care for on the other side as well - the char device. So yes, I can break it up, but that would result in uncompilabe intermediate states that I wanted to avoid. If you have an idea about how that could be nicely done, please let me know :) Daniel -- 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
