On Sat, Jun 16, 2012 at 01:23:51AM +0200, Daniel Mack wrote: > 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 :) Hm, you are right, we can't have broken steps. From the description above, I thought you were doing two different things here. But if it's really just one, then we will just have to live with it as-is. thanks, greg k-h -- 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
