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.
Dan
>
>
>
>
>
>
>
>
>
> At 2014-06-23 05:33:55, "Johan Hovold" <johan@xxxxxxxxxx> wrote:
> >On Fri, Jun 20, 2014 at 06:30:23PM +0800, 刘磊 wrote:
> >> patch2: Modify the parameter from 0x0003 to 0x0000. you must submit patch1 at first.
> >> Reason:In the USB serial protocol, if set the control state
> >> (SET_CONTROL_LINE_STATE(22h)) and the parameter of RTS must be 0x0000
> >> that make the carrier signal invalid state when close network.
> >> otherwise can't disconnect the network.
> >
> >Ok, that makes sense, but I think it should be implemented differently
> >using the infrastructure provided by usb-serial (and tty-port).
> >
> >I'm responding to this mail with two patches.
> >
> >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?
> >
> >When you you have tested the first patch, could you test the second one
> >as well and see if everything still works?
> >
> >Thanks,
> >Johan
> NrybXǧv^){.n+{^nrzh& Gh(階ݢj"mzޖfh~m
--
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
