Dear johan&Williams
As we discuss about the question of zte_ev.c, are you sure how to modify.
Looking forward to your reply. thanks.
lei.liu
At 2014-06-25 04:35:28, "刘磊" <lei35...@163.com> wrote:
>
>
>At 2014-06-24 09:46:01, "Johan Hovold" <jo...@kernel.org> wrote:
>>On Tue, Jun 24, 2014 at 08:43:36PM +0800, 刘磊 wrote:
>>> At 2014-06-23 10:49:14, "Johan Hovold" <jo...@kernel.org> wrote:
>>> >On Mon, Jun 23, 2014 at 09:42:08AM -0500, Dan Williams wrote:
>>> >> On Mon, 2014-06-23 at 18:15 +0800, 刘磊 wrote:
>>
>>> >> > 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.
>>
>>It sounds like it's time to drop zte_ev and move all PIDs back to
>>option. The magic setup packets turned out to not do anything magic (and
>>still failed to get it right, with respect to the interface argument),
>>while everything appears to work fine, or rather better (e.g. DTR/RTS),
>>with the generic option driver.
>>
>>If someone wants to do an effective revert of commit 73228a0538a7 ("USB:
>>option,zte_ev: move most ZTE CDMA devices to zte_ev") (i.e. make sure to
>>restore PID defines and quirks) and then move the remaining PIDs added
>>by 799ee9243d89 ("USB: serial: add zte_ev.c driver") before removing the
>>driver, I'll take those patches.
>>
>>Anyone against?
>
>commit 799ee9243d89 ("USB: serial: add zte_ev.c driver")
>i had see the commit, the file of zte_ev.c is modify according to the drive of
>our company,
>the drive was used in the old linux version when the pid was not add in
>option.c.
>
>commit 73228a0538a7 ("USB:option,zte_ev: move most ZTE CDMA devices to zte_ev")
>the commit had been add the rest of the pid to zte_ev.c, the pid moved into
>zte_ev.c is the same as our company early driver.
>
>
>>
>>Thanks,
>>Johan
