On Mon, Jun 23, 2014 at 09:42:08AM -0500, Dan Williams wrote: > On Mon, 2014-06-23 at 18:15 +0800, 刘磊 wrote: > > >Could you try the first patch (only) and see if it fixes the problem? > > >Does it also fix the problem you're having with PID 0xfffe? > > > > yes, the first patch could solve the problem with pid 0xfffe. > > > > > > >When you you have tested the first patch, could you test the second one > > >as well and see if everything still works? > > > > yes, the second path i had been tested and it works fine. > > > > > > In you other two mails, you want to modify the line-coding handling, but i'm not sure that have some problem. > > otherwise, it will be have some problem in the pid of 0xfffe for our company(the pid of 0xfffe belongs our company). > > i suggest you sould move the pid of 0xfffe from zte_ev.c to option.c at first and then modify others. > > > > > > i don't know why create the file of zte_ev.c that is not necessary. i suggest we can move all the pid from zte_ev.c to option.c. > > The file is derived from the zte_ev.c that was distributed by ZTE > themselves in the "ztemtApp" software for 0xffeb -> 0xffff, 0x3917, > 0x6000, and 0x9008, which include the AC8700, AC8710, MG880, AC2726, > AC8710_V3, AC2716, and a bunch of other CDMA devices. They were > originally driven by option, but users were having problems with that > and I think people thought that maybe the "official" ZTE drivers would > work better. > > I would like to move them to option if we can, and get rid of zte_ev.c, > but to do that we must understand what zte_ev.c was actually trying to > do so that we ensure that option can do it too. I fully agree. If these ZTE devices still work with the two patches I sent, they could probably still work without the remaining SET_LINE_CODING (9600 8N1), and in that case there really isn't any difference to the option driver (control-message wise). Johan -- 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
