Hi Felipe, On 08/29/2014 10:46 PM, Felipe Balbi wrote: > On Wed, Aug 27, 2014 at 07:09:03PM +0200, Daniel Mack wrote: >> Restructure some code to make it easier to read. >> >> While at it, return -ENOMEM instead of -EINVAL if >> usb_ep_alloc_request() fails, and omit the logging in such cases >> (the mm core will complain loud enough). >> >> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx> >> --- > > does this depend on anything ? It doesn't apply to my testing/next > The reason it doesn't apply is that you already applied v6 of my series to your testing/next tree: https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=c52425b The currently pending discussion is about how to determine the size of the packets sent down to the host, and it only affects the last patch in the series. To summarize, here are the two approaches to do this: 1) We pre-calculate a pattern of lengths which is then followed when sending the packets. This is what Jassi implemented in his alternative approach to my version here: http://www.spinics.net/lists/linux-usb/msg112913.html This idea comes at the price of storing the pre-calculated sequence and track its state, which currently means adding 163 unsigned ints to the device's private structs. This, however could be reduced by only storing the pattern for the capture side and by using u8 or u16 instead of unsigned int for the pattern store. I haven't yet tested this version, though. 2) We keep track of the number of sent bytes and do an ad-hoc determination on how big the next packet should be, each time we send one to the host. This is what my v6 does, which you already have in your tree. This comes at the price of storing and maintaining 5 unsigned ints for keeping track of the current state and some pre-calculated numbers (so we don't have to do that for every packet), plus some calculations to be done for every packet. If we want to go for this solution, we don't have to add any patch on top. So, ultimately, it's a matter of trade-off, memory footprint vs. maintenance of 3 more state variables vs. some calculation done for each of the packets (~1000 per second). I really don't feel like arguing over this much, but my impression is that the currently applied version is more comprehensible, and the overhead caused by the calculation is not measurable (we do a lot more of such arithmetic in the snd-usb driver for each packet). So, decide for yourself which way to go, and let us know if you want any further action to be taken. Thanks, 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
