Hello, I'm reimplementing a driver for the serial ports of the NetSilicon 9360 processor and have a few questions concerning this. For your information, I'm using v2.6.21-rc3 and if your interested in the specs of the UART, you can find it at http://ftp1.digi.com/support/documentation/90000675_C.pdf - I cannot find anything about out1 and out2 in the HRM. Are these signals optional? (set_mctrl) - The UART has two different loopback modes. Citing the HRM: - Remote loopback (RL) Provides a remote loopback feature. When RL is set to 1, the TXD transmit output is connected to the RXD receive input. The RL field immediately echoes receive data back as transmit data. This field is used primarily as a test vehicle for external data equipment. - Local loopback (LL) Provides an internal local loopback feature. When LL is set to 1, the internal receive data stream is connected to the TXD output signal. LL connects the serial channel receiver directly to the serial channel transmitter. This field is used primarily as a test vehicle for the serial channel driver firmware. I think I should set at least LL in set_mctrl, if mctrl has TIOCM_LOOP set. What about RL, should I set that, too? - Documentation/serial/driver lists the bits relevant for get_mctrl. One of them is TIOCM_DCD. When grepping for that in the linux tree, the only match is Documentation/serial/driver itself. The reference implementation (amba_pl011.c) uses TIOCM_CAR instead. Probably the documentation should be fixed? - grepping for TIOCM_RI shows that for all architectures this is defined as follows: #define TIOCM_RI TIOCM_RNG For me it looks as if TIOCM_RI were deprecated? If so, Documentation/serial/driver should better use TIOCM_RNG? amba_pl011.c uses TIOCM_RNG, too. For now that's it, but I expect to have some more questions as the driver is far from being complete. Best regards Uwe -- Uwe Kleine-König http://www.google.com/search?q=half+a+cup+in+teaspoons - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html