On Monday 15 December 2003 04:47pm, Greg KH wrote:
> On Sat, Dec 13, 2003 at 01:05:20PM -0500, Marr wrote:
> > On Friday 12 December 2003 03:22pm, Greg KH wrote:
> > > On Thu, Nov 27, 2003 at 01:57:28AM -0500, Marr wrote:
> > > > On Wednesday 26 November 2003 12:22pm, Greg KH wrote:
> > > > > On Tue, Nov 25, 2003 at 02:59:52PM -0500, Marr wrote:
> > > > > > Greg K-H et al,
> > > > > >
> > > > > > Greetings....
> > > > > >
> > > > > > A little less than 3 weeks ago (on Nov 5th), I sent a patch to
> > > > > > this list. Here's an excerpt from my initial email:
> > > > >
> > > > > Can you send it again? I did not see it, sorry.
> > > >
> > > > Sure, no problem. (The first time I sent this, it was only to the
> > > > mailing list, not directly to you, Greg. Was that appropriate?)
> > > >
> > > > Enclosed is the original message with attachments.
> > > >
> > > > Feel free to holler in my direction if any questions arise.
> > >
> > > Thanks, I've applied the patch to 2.4, but the 2.6 one seems mangled
> > > somehow. Can you resend that one to me again, with the same text
> > > information at the top of it (it will show up in the changeset.)
> >
> > Greg,
> >
> > Per your request, attached is the original text and the original patch
> > file for 2.6.
>
> Ick, same error :(
> Yeah, something is wrong, I get the following when trying to apply your
> patch:
> [EMAIL PROTECTED] serial]$ patch -p1 -g1 --dry-run <
> ~/linux/patch-2.6.0-test9.txt mct_u232.c 1.51: 891 lines
> patching file mct_u232.c
> patch: **** malformed patch at line 68: diff -u ../mct_u232.h ./mct_u232.h
Ack! A thousand pardons, sir....
I've gotten back to the machine with the 2.6.0-test9 kernel and realized that
I get the same error.
As it turns out, it was just a dollop of missing whitespace (a single blank
line) that was causing the problem. I don't know how that disappeared, but my
apologies for wasting your time with the bad patch.
I've re-'diff'ed the patch per your suggestions. The new (attached) patch
applies cleanly for me.
Bill Marr
diff -Nru test9/drivers/usb/serial/mct_u232.c
test9-patched/drivers/usb/serial/mct_u232.c
--- test9/drivers/usb/serial/mct_u232.c 2003-11-04 19:25:48.000000000 -0500
+++ test9-patched/drivers/usb/serial/mct_u232.c 2003-11-05 17:34:44.000000000 -0500
@@ -24,6 +24,11 @@
* Basic tests have been performed with minicom/zmodem transfers and
* modem dialing under Linux 2.4.0-test10 (for me it works fine).
*
+ * 04-Nov-2003 Bill Marr <marr at flex dot com>
+ * - Mimic Windows driver by sending 2 USB 'device request' messages
+ * following normal 'baud rate change' message. This allows data to be
+ * transmitted to RS-232 devices which don't assert the 'CTS' signal.
+ *
* 10-Nov-2001 Wolfgang Grandegger
* - Fixed an endianess problem with the baudrate selection for PowerPC.
*
@@ -85,7 +90,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v1.1"
+#define DRIVER_VERSION "v1.2"
#define DRIVER_AUTHOR "Wolfgang Grandegger <[EMAIL PROTECTED]>"
#define DRIVER_DESC "Magic Control Technology USB-RS232 converter driver"
@@ -216,6 +221,7 @@
{
unsigned int divisor;
int rc;
+ unsigned char zero_byte = 0;
divisor = cpu_to_le32(mct_u232_calculate_baud_rate(serial, value));
rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
MCT_U232_SET_BAUD_RATE_REQUEST,
@@ -225,6 +231,35 @@
if (rc < 0)
err("Set BAUD RATE %d failed (error = %d)", value, rc);
dbg("set_baud_rate: value: %d, divisor: 0x%x", value, divisor);
+
+ /* Mimic the MCT-supplied Windows driver (version 1.21P.0104), which
+ always sends two extra USB 'device request' messages after the
+ 'baud rate change' message. The actual functionality of the
+ request codes in these messages is not fully understood but these
+ particular codes are never seen in any operation besides a baud
+ rate change. Both of these messages send a single byte of data
+ whose value is always zero. The second of these two extra messages
+ is required in order for data to be properly written to an RS-232
+ device which does not assert the 'CTS' signal. */
+
+ rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
+ MCT_U232_SET_UNKNOWN1_REQUEST,
+ MCT_U232_SET_REQUEST_TYPE,
+ 0, 0, &zero_byte, MCT_U232_SET_UNKNOWN1_SIZE,
+ WDR_TIMEOUT);
+ if (rc < 0)
+ err("Sending USB device request code %d failed (error = %d)",
+ MCT_U232_SET_UNKNOWN1_REQUEST, rc);
+
+ rc = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
+ MCT_U232_SET_UNKNOWN2_REQUEST,
+ MCT_U232_SET_REQUEST_TYPE,
+ 0, 0, &zero_byte, MCT_U232_SET_UNKNOWN2_SIZE,
+ WDR_TIMEOUT);
+ if (rc < 0)
+ err("Sending USB device request code %d failed (error = %d)",
+ MCT_U232_SET_UNKNOWN2_REQUEST, rc);
+
return rc;
} /* mct_u232_set_baud_rate */
diff -Nru test9/drivers/usb/serial/mct_u232.h
test9-patched/drivers/usb/serial/mct_u232.h
--- test9/drivers/usb/serial/mct_u232.h 2003-07-27 13:09:43.000000000 -0400
+++ test9-patched/drivers/usb/serial/mct_u232.h 2003-11-05 16:57:08.000000000 -0500
@@ -57,6 +57,21 @@
#define MCT_U232_SET_MODEM_CTRL_REQUEST 10 /* Set Modem Control Register (MCR)
*/
#define MCT_U232_SET_MODEM_CTRL_SIZE 1
+/* This USB device request code is not well understood. It is transmitted by
+ the MCT-supplied Windows driver whenever the baud rate changes.
+*/
+#define MCT_U232_SET_UNKNOWN1_REQUEST 11 /* Unknown functionality */
+#define MCT_U232_SET_UNKNOWN1_SIZE 1
+
+/* This USB device request code is not well understood. It is transmitted by
+ the MCT-supplied Windows driver whenever the baud rate changes.
+
+ Without this USB device request, the USB/RS-232 adapter will not write to
+ RS-232 devices which do not assert the 'CTS' signal.
+*/
+#define MCT_U232_SET_UNKNOWN2_REQUEST 12 /* Unknown functionality */
+#define MCT_U232_SET_UNKNOWN2_SIZE 1
+
/*
* Baud rate (divisor)
*/
@@ -137,22 +152,31 @@
* Baud rate (divisor)
* -------------------
*
- * BmRequestType: 0x4 (0100 0000B)
- * bRequest: 0x5
- * wValue: 0x0
- * wIndex: 0x0
- * wLength: 0x4
+ * BmRequestType: 0x40 (0100 0000B)
+ * bRequest: 0x05
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0004
* Data: divisor = 115200 / baud_rate
*
+ * SniffUSB observations (Nov 2003): Contrary to the 'wLength' value of 4
+ * shown above, observations with a Belkin F5U109 adapter, using the
+ * MCT-supplied Windows98 driver (U2SPORT.VXD, "File version: 1.21P.0104 for
+ * Win98/Me"), show this request has a length of 1 byte, presumably because
+ * of the fact that the Belkin adapter and the 'Sitecom U232-P25' adapter
+ * use a baud-rate code instead of a conventional RS-232 baud rate divisor.
+ * The current source code for this driver does not reflect this fact, but
+ * the driver works fine with this adapter/driver combination nonetheless.
+ *
*
* Line Control Register (LCR)
* ---------------------------
*
- * BmRequestType: 0x4 (0100 0000B) 0xc (1100 0000B)
- * bRequest: 0x7 0x6
- * wValue: 0x0
- * wIndex: 0x0
- * wLength: 0x1
+ * BmRequestType: 0x40 (0100 0000B) 0xc0 (1100 0000B)
+ * bRequest: 0x07 0x06
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0001
* Data: LCR (see below)
*
* Bit 7: Divisor Latch Access Bit (DLAB). When set, access to the data
@@ -186,18 +210,18 @@
*
* SniffUSB observations: Bit 7 seems not to be used. There seem to be two bugs
* in the Win98 driver: the break does not work (bit 6 is not asserted) and the
- * sticky parity bit is not cleared when set once. The LCR can also be read
+ * stick parity bit is not cleared when set once. The LCR can also be read
* back with USB request 6 but this has never been observed with SniffUSB.
*
*
* Modem Control Register (MCR)
* ----------------------------
*
- * BmRequestType: 0x4 (0100 0000B)
- * bRequest: 0xa
- * wValue: 0x0
- * wIndex: 0x0
- * wLength: 0x1
+ * BmRequestType: 0x40 (0100 0000B)
+ * bRequest: 0x0a
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0001
* Data: MCR (Bit 4..7, see below)
*
* Bit 7: Reserved, always 0.
@@ -226,11 +250,11 @@
* Modem Status Register (MSR)
* ---------------------------
*
- * BmRequestType: 0xc (1100 0000B)
- * bRequest: 0x2
- * wValue: 0x0
- * wIndex: 0x0
- * wLength: 0x1
+ * BmRequestType: 0xc0 (1100 0000B)
+ * bRequest: 0x02
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0001
* Data: MSR (see below)
*
* Bit 7: Data Carrier Detect (CD). Reflects the state of the DCD line on the
@@ -287,6 +311,41 @@
* minicom/zmodem transfers (CRC errors).
*
*
+ * Unknown #1
+ * -------------------
+ *
+ * BmRequestType: 0x40 (0100 0000B)
+ * bRequest: 0x0b
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0001
+ * Data: 0x00
+ *
+ * SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver
+ * (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request
+ * occurs immediately after a "Baud rate (divisor)" message. It was not
+ * observed at any other time. It is unclear what purpose this message
+ * serves.
+ *
+ *
+ * Unknown #2
+ * -------------------
+ *
+ * BmRequestType: 0x40 (0100 0000B)
+ * bRequest: 0x0c
+ * wValue: 0x0000
+ * wIndex: 0x0000
+ * wLength: 0x0001
+ * Data: 0x00
+ *
+ * SniffUSB observations (Nov 2003): With the MCT-supplied Windows98 driver
+ * (U2SPORT.VXD, "File version: 1.21P.0104 for Win98/Me"), this request
+ * occurs immediately after the 'Unknown #1' message (see above). It was
+ * not observed at any other time. It is unclear what other purpose (if
+ * any) this message might serve, but without it, the USB/RS-232 adapter
+ * will not write to RS-232 devices which do not assert the 'CTS' signal.
+ *
+ *
* Flow control
* ------------
*
