Linux user space: how to put 16550-compatible UART in loopback mode persistently

Question

There is an 16550-compatible UART on the market that I would like to configure. The Linux driver is provided by the manufacturer, and I have to configure the (multiple-)UART through an user-space program, persistently.

Persistence means that the configuration remains inside the chip even after my configurator exits.

The problem that I encountered is that the uart_ops operations in the kernel driver seems to affect the content of the MCR (Modem Control Register) through its .startup and .shutdown operations. The task at hand is to put the UART in Loopback mode, through setting the bit5 (from 0 to 7) of the MCR register to 1. I do that through a manufacturer-provided IOCTL (are there any other ways, BTW?), but to access the IOCTL, I have to provide a file descriptor: that means an open(). Then, when my configurator exits, the system close() the file descriptor.

As such, the uart_ops.shutdown() function is called and the content of my MCR is lost. Subsequent application do not see the UART in loopback mode, so no way to test.

How to do that? Open the port/associated device node, then enabling the loopback in MCR and then never closing the descriptor (through sleeping or infinite loop)? Is that an acceptable solution? Would subsequent application be able to see the UART in loopback mode?

How to avoid calling the uart_ops.shutdown function and the MCR-overwrite it performs before subsequent applications test the loopback mode?

Thank you.

Edit:

The UART in question is Exar XR17D158 (http://www.exar.com/connectivity/uart-and-bridging-solutions/pci-uarts/pci-uarts-universal-3-3v-or-5v/xr17d158) and the driver is found here: http://www.exar.com/common/content/document.ashx?id=20639&languageid=1033 The serialxr_startup and serialxr_shutdown that are passed as uart_ops.startup and uart_ops.shutdown members are at lines 806 and 902 in the xr17c15x.c file.

Answer 1

I finally solved the problem: by not allowing the Exar driver to ever call its uart_ops.shutdown() function: I simply open() the device file at the beginning, and never close() it to avoid the driver calling the uart_ops.shutdown() function. To prevent the operating system to automatically call close() at the end of the program, I simply put it into an infinite loop:

while(1) {
        sleep(100);
}
return 0; //unreachable

Apparently, the driver calls uart_ops.shutdown() whenever the last close() is called. To prevent that to happen, I ensure thus that at least one close() is still needed to be called, by maintaining an open() on the device file.

Answer 2

It sounds like the real issue is that you don't want Linux to second-guess you by automatically loading your kernel driver - and auto-initialize the device - at boot time.

If so, your best bet is probably to configure "modprobe.conf" to disable auto-loading of your vendor's kernel driver:

• http://www.cyberciti.biz/tips/avoid-linux-kernel-module-driver-autoloading.html

If this works, you can "enhance" the solution by adding your own startup scripts to configure things your own way. If you wish to.

'Hope that helps!