>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.
At 2014-06-23 05:33:55, "Johan Hovold" <jo...@kernel.org> 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
N�����r��y����b�X��ǧv�^�){.n�+����{������^n�r���z���h�����&�� �G���h�(�階�ݢj"���m������z�ޖ���f���h���~�m�
