From: Martin D. <li...@md...> - 2004-03-04 08:15:54
|
On Wed, 3 Mar 2004, David James Brockley wrote: > > Are there any specifications, technical documents, datasheets or h/w > > diagrams for the pl2303 and the ma600 ?? > > (I guess there are no specs for the ma620) > > > > I'd like to take a look at the modules' code and try my luck with > > usbsnoopy, but firstly, and if it is feasible, I'd like to have a > > better understanding on how all these hardware components communicate > > with each other. > > I have found an old (2001) driver on the Prolific website that seems to have > substantial differences with the current driver - the bits in status bytes > seem to be representing different things, for example. IIRC, it was claimed several times this driver would be worse than the one we have in the current kernel - personally, I haven't tried to compare them. > I've done a USBSnoop run and had a look at the output. This seems to be > different again to the other two drivers. I think at this stage we need a > description of the protocol to refer to. Has anyone contacted Greg > Kroah-Hartman, the maintainer of the pl2303 driver yet? If not, I'll see if I > can get some input from him. AFAIK the cuurent in-kernel pl2303 driver was done without sufficient documentation. > I've narrowed down the problem a bit further (I think). Some of my test runs > work ok. These tend to be the second and subsequent repeats of loading the > modules and running irdadump. When a test fails, there is always a call of > the pl2303_read_int_callback immediately before the > pl2303_read_bulk_callbacks start with the discovery data read from the other > device. This read_int contains 0x10 at buffer[8] which gets copied into > line_status and then gets picked up as a frame error on every subsequent > read_bulk. Calls to read_int seem to be the only way that line_status gets > set. Arghh - while trying to follow this I just realized the pl2303 is DMA'ing to the stack - not good! Could you please just try with the patch below. I'm not sure if this might cause the MA620 trouble but it's definedly a bug and maybe it improves things for you... > There seems to be some code in usbserial to work around problems with certain > revisions of the pl2303. I've tried causing that to get called, but it did > not seem to make any difference. My current train of thought is that I have a > revision of the pl2303 that has a different set of incompatibilities to be > worked around :-( > > If anyone wants my USBSnoop log (or can tell me what it means :-), let me > know. Any pointers to good information on how USB works would be appreciated > as well, beyond that in the 1.1 spec document. Not making any promises wrt. to available time - but you might mail me the usbsnoop logs. If possible I'm trying to check against the ma600 protocol. linux/Documentation and kernelsource might provide some more USB insight. Martin ---------------------------------- --- linux-2.6.3-bk9/drivers/usb/serial/pl2303.c Mon Jan 26 12:56:17 2004 +++ v2.6.3-bk9-md/drivers/usb/serial/pl2303.c Thu Mar 4 08:42:18 2004 @@ -403,7 +403,7 @@ static int pl2303_open (struct usb_seria { struct termios tmp_termios; struct usb_serial *serial = port->serial; - unsigned char buf[10]; + unsigned char *buf; int result; if (port_paranoia_check (port, __FUNCTION__)) @@ -414,6 +414,10 @@ static int pl2303_open (struct usb_seria usb_clear_halt(serial->dev, port->write_urb->pipe); usb_clear_halt(serial->dev, port->read_urb->pipe); + buf = kmalloc(10, GFP_KERNEL); + if (buf==NULL) + return -ENOMEM; + #define FISH(a,b,c,d) \ result=usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev,0), \ b, a, c, d, buf, 1, 100); \ @@ -432,6 +436,8 @@ static int pl2303_open (struct usb_seria SOUP (VENDOR_WRITE_REQUEST_TYPE, VENDOR_WRITE_REQUEST, 0x0404, 1); FISH (VENDOR_READ_REQUEST_TYPE, VENDOR_READ_REQUEST, 0x8484, 0); FISH (VENDOR_READ_REQUEST_TYPE, VENDOR_READ_REQUEST, 0x8383, 0); + + kfree(buf); /* Setup termios */ if (port->tty) { |