On Wed, Aug 03, 2016 at 03:33:21PM -0600, Theo de Raadt wrote: > > I don't think the com(4) part of the diff is quite right. This busy > > indicator feature seems to be specific to the Designware core. I > > can't find the original NS16750 datasheet (was there ever one?), but > > it isn't present on any of the true 16750 clones. So I think that > > instead of adding a COM_HW_IIR_BUSY flag, we should add a > > COM_UART_DWAPB type and use that to signal the presence of this > > feature. > > Patrick send me a newer version of the diff with better documentation. > > And that makes the same is clear to me. At least one of these flags > should be changed to make sure it is narrowly specific to this > particular defective chip implementation. > > > The comments should certainly not mention the NS16750. > > Right. In any case it is not a NS16750. It is a fresh piece of > hardware, that mostly behaves like a NS16750, except in at least this > way. (A whole generation of shitty chips are supersets of NS16750). >
Iirc. it is 8250. "* The Synopsys DesignWare 8250 has an extra feature whereby it detects if the * LCR is written whilst busy. If it is, then a busy detect interrupt is * raised, the LCR needs to be rewritten and the uart status register read." (about placing uart.c; fwiw., i'd start by moving arch/arm/cortex/* under arch/armv7/dev/, and do rest of the likely upcoming generic/shared code/glue/drivers there.) -Artturi > > But I'd also like to look at the documentation to see if there way to > > work around this issue. It seems that the interrupt handlers is > > simply waiting for the FIFO to drain. It would really surprise me if > > that is really necessary. > > I suspect the chip was implimented as a microcode, and they made a > mistake, so they added a flag. It am guessing the interrupt stays > asserted. Stalling in the interrupt handler seems odd. I'm going to > guess this only happens once, at startup? That might match Mark's > theory. >
