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]

 



On Tue, Jun 24, 2014 at 08:43:36PM +0800, 刘磊 wrote:
> 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:

> >> > 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?

Thanks,
Johan
--
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




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

  Powered by Linux