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
