Re:Re: Re:Re: move ZTE CDMA device pid from zte_ev.c back to option.c and modify a parameter in zte_ev.ko

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




At 2014-06-23 10:49:14, "Johan Hovold" <johan@xxxxxxxxxx> wrote:
>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).

the pid in zte_ev.c beloging to the various subsidiaries of ZTE. 
Now i can confirm the id of fffe,ffff,fffed,fffeb can work fine in option.c. 
the id from fff9 to fffb and ffee belonging other subsidiaries, we asked and they did not create the file of zte_ev.c. 
and the other id of 0x05C6 may belong to Qualcomm, I don't think it add by Qualcomm.

>
>Johan
��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux