I'm not an OpenBSD user, I'm not asking for help. I'm posting here because OpenBSD was the only mention of this device I found when searching the net. My device also identifies as 0x4651 0x3273, though marked as PCI 60806 instead of TX382B. I never found a data sheet for it, but after some trial and error reverse engineering, I discovered its quirks.
a) As reported in the subject thread, MCR loopback is non functional. But the UART has a standard 16 byte FIFO, thus probing its depth is not necessary. b) In a normal UART, you see THRE interrupt after clearing higher priority interrupts (LINE and RECV). As the PC16550D data sheet says, THRE is reset by: "Reading the IIR Register (if source of interrupt) or Writing into the Transmitter Holding Register" The point of note is that reading the IIR will not clear THRE from the IIR unless it's the source of interrupt. Reading the IIR when LINE and RECV interrupts are active will leave the THRE indication intact, and you will see it as expected, after LINE and RECV interrupts are cleared. However, the 60806 / TX382B does not work that way. Any read of the IIR clears the THRE indication. So if you get a LINE or RECV indication when reading IIR, if THRE was there, it's now lost. You only see a THRE indication if it was the highest priority interrupt pending when reading the IIR. Losing THRE interrupts is a problem if your code assumes a standard UART and relies on THRE interrupts to keep transmission going. Once I understood that quirk, I was able to work around it. c) Unlike a normal UART, you cannot clear LSR error bits or LINE status interrupt by reading the LSR. This will cause havoc when you get a frame or break error, because you can't clear the interrupt, and that means trouble. I was able to crash linux by inducing a break / frame error when powering off my device attached to a null modem cable. This had me stumped at first, I thought it made the UART worthless. But after more testing, I discovered the LSR error bits and LINE status interrupt *auto* clear themselves, upon reception of the next good data byte. Until that happens, the error bits and LINE status interrupt are stuck on. Understanding that quirk, you can work around it too.
