I have a Kyocera 7135 cell phone and the Kyocera TXDTA0C01 USB data cable. I was interested in using it to do wireless networking with my linux portable. I cracked open the tiny dongle in the cable and it's using the KLSI KL5KUSB105 chip.
I updated the Vendor/Product IDs (they're 0x0c88/0xa226) for the cable to the kl5kusb105.h and update the .c file's table, hoping for the easy fix. No such luck. So I ended up playing with USB snoopy, my logic analyzer and clips, and over the past few days I've learned a lot about this particular KL5KUSB105 implementation that seems to match closely what's going on in the linux driver code, but I think I can offer a bit more detail and explain certain parts of the code that were "well, this is that windows does, so we'll do it too." Hopefully someone will find this useful, as it should let some "FIXMEs" to be corrected regarding implementation of TERMIO support, and maybe get me closer to a working cable. First, the code notes that there's a five-byte configuration structure (klsi_105_port_settings), but has two unknown bytes. Here's the explanation for the unknown bytes and a programming table for the configuration: <05> <baud> <bits> <parity> <stop bits> Coding is as follows: <baud>: 0x00:115200 0x01:57600 0x02:38400 0x03:Unk 0x04:19200 <baud>: 0x05:unk 0x06:9600 0x07:Unk 0x08:4800 0x09:2400 <baud>: 0x0a:1200 0x0b:600 <bits>: 0x08:8 bits 0x07:7 bits 0x06:6 bits 0x05:5 bits <parity>: 0x00:none 0x01:odd 0x02:even 0x03:mark <stop>: 0x00:1 stop bit 0x02:2 stop bits It appears rates slower than 600 baud, "space" parity, 1.5 stop bits and the "break" signal on the TxD line are not supported, at least not in the windows driver. Note that my cable seems to support 5 and 6 bits though the linux klsi driver claims otherwise. The driver lists some speeds for the unknowns that weren't listed options with the windows driver I used. There are three known USB requests that the linux driver is using presently, but the function of the third request is seriously misunderstood from my reading of the code. The requests as I found while snooping were: UART_CONFIG (0x01) Sets the UART communications parameters using the five-byte configuration data structure above. (This is called KL5KUSB105A_SIO_SET_DATA in the driver.) UART_POLL (0x02) Causes the KLSI chip to respond with a two-byte poll response. (Labeled KL5KUSB105A_SIO_POLL) In the driver the author is aware the low byte of the poll response has DSR and CTS in it, but not which is which. It also has Data Carrier Detect and Ring Indicator in it as well. The mapping is: CTS 0x10 DSR 0x20 RI 0x40 DCD 0x80 UART_CONTROL (0x03) uses the Value in the usb_control_msg request to set RTS and DTR signals. Here's where the driver author was mistaken, as he believed it was what turned the UART's read function on and off, when he was really turning DTR on and off, and the palm device was interpreting that as a handshaking signal and sending or not based on DTR. My 7135 has the option of turning off handshaking and data was happily received with DTR off, and when I toggled DTR/RTS with comm port test software on windows, this is the request that was used, so it's no read enable switch. Note this solves the mystery mentioned in the driver of how to turn them on and off, as the author was already doing it. :-) The mapping for DTR and RTS in Value is: DTR 0x01 RTS 0x02 (Pretty much like all the other USB->serial devices.) MYSTERY (0x05) Seen, function unknown, all zero values in the rest of the request. It may be a reset command, it only seems to pop up as the next request after a UART_CONFIG request. The windows driver appears to frequently resend of the UART configuration data during DTR and RTS signal changes, which the linux driver appears to emulate by accident (the mistaken "read on" after setting up the UART.) I think this may be a windows driver issue or better-safe-than-sorry coding. This seems to happen the most around RTS changes. Anyway... I've hacked on the kl5kusb105 driver code for 2.4.22 (which is in the slack distro I use) for a couple days and while getting the TERMIO code to work was trivial, getting the data to work has been a nightmare as I pretty much get an OOPS every time. Since it's old code and I've hacked it into oblivion and it still doesn't work, I'll spare the details. However the linux driver and the windows driver seems to be divergent on some finer points -- maybe it's specific to the kyocera cable: One thing I noticed is that the windows driver pretty much launches a bulk read request with transfer flags of 0x00000003 first thing, and always keeps it pending, relaunching a new one after getting data. (I'm interpreting the flags as USB_DIABLE_SPD | USB_ISO_ASAP, though who knows...) I'm pretty sure this is the proper way to read data. The linux driver appears to try do the same, though the transfer flags are a bit off, and it lets the URB die without a restore if there are non-zero bulk read status returns (I see -121, USB_ST_SHORT_PACKET, which is consistent with the empty bulk reads I see on the windows driver snoop after a full bulk read takes place.) Anyway, I think this is stopping any data from getting though -- but I'm not sure at all. I had one brief moment of hope after hacking the transfer flags where I got some data before a OOPS, but it hasn't been repeatable since. :-( This is the area I'm probably most concerned about, between the OOPSes and the substantial changes in code from the existing driver, and maybe I'm just missing something... Similarly, on transmit I'm seeing transfer flags of 0x0 on the windows driver, and the linux driver is using USB_QUEUE_BULK, not sure if it matters, however. Anyway - after a few days of working on this I thought I'd share what I had, plus I'm not sure how much more work I will do on this, nor does it necessarily make sense for me to be hacking on 2.4 rather than 2.6. (BTW, I know about the USB serial OOPS problems on the .22 kernels) That said, if anyone can hit this newbie with a clue stick that would result in an easy fix, please do so! ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
