Hi! >>>>> "KY" == Kaliuta Yauheni writes: > >>>>> "eSB" == ext Sjur BRENDELAND writes: > > greg@xxxxxxxxxxxxxxxx wrote: > > > How does this relate to the CDC-NCM driver[1] submitted by Yauheni > > > Kaliuta (Nokia) on April 16th that were submitted for merging in May? > > > It would seem that we only want one CDC-NCM implementation in the > > > kernel, right? > > > > > The previous RFC submission from Yauheni Kaliuta is a "proof of concept" > > for NCM that does not have lower CPU usage or higher throughput than > > ECM. This is the first submission of NCM that allows a limited device > > to take advantage of the NCM spec and achieve higher throughput with > > lower CPU utilization. The submitted code has also been tested on a > > number of architectures and seems to be reasonably stable. > > We want to see a high performance, high quality NCM driver into the > > kernel regardless of who wrote the code. > I like the submitted driver, well done! But I think we really should agree > some design issues. I mostly interested in the gadget driver, you are in > the host one (and actually I started to do the host part only because I did > not have any implementation around), but I think we should share as much as > possible. > My ideas during the implementation were: > 1) reuse existing code as much as possible > 2) share host/gadget code as much as possible (if you check, the parser/packer > code actually the same and the same includes are used) > You try to > 1) isolate the code as much as possible. > And I actually understand, why it can be reasonable. > So, I think we should > 1) agree about generic (spec related) includes at > least. It affects implementation a bit, because we use data types > differently. I prefer my approach, because it fits the existing kernel > code, I think. So, we had an offline discussion, where agreed the includes. I'm submitting the patches now. > 2) It would be very very good, if we agree about common ncm-protocol > related code/includes. Should take into account, should we support other So, for now it's fine for me, if we submit the parts separately. One of the reasons, is that the host and gadget parts are in different subtrees now. After that we can create a common place or even think of moving of the host-side parts. Anyway, we at least do not block each other. > parts of protocol, like 32bits and so on (I tried to do it, but may be we > should drop it?). Still under discussion. > 3) Discuss the actual implementaion. > I'm on vacations the next week, so can continue later. Well, .. :) -- WBR, Yauheni Kaliuta JID: ykaliuta@xxxxxxxxxxxxxxxxxxxxx -- 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
