> > If we have different UART drivers, only one of them provides ttyS*, no? > > Other drivers will have to use another namespace. > > I remember this was a problem a couple of years ago last I tried, with > the 8250 driver being actually preventing other drivers from using > ttyS*, but if you don't have 8250 taking over the low ttyS numbers, you > may run into a case where several drivers successfully register their > character devices under a ttyS* numbering scheme. > > Whether this is hypothetical or not nowadays, it may be nicer to provide > a more uniquely distinct name like what dev_name() returns, or > ttyS*-driver-tx for instance? It needs to be at the tty layer anyway or you will break low end machines. On a low end system with a 16450A UART you've got something like 160 microseconds at 57600 baud before you must have exited the IRQ handler, re-entered it and be reading the data register again. The current proposed patches touching the 8250 IRQ path are almost certainly going to cause regressions on old machines. So you need to hook receive at a point outside of the IRQ layer (eg when the workqueue starts feeding it into the ldisc), but on the tx side you need to hook the write method of the tty really, because tty_write sends data to the ldisc and what happens then is up to the ldisc. Even there though you have cases that are terribly latency dependant like some of the dumb programming tools that don't window. If you halve someones programming rate for microcontrollers you are going to get hate mail 8) For RX that can mostly be avoided by queuing the data then doing the LEDs, for TX I'm not clear you can easily hide the latency. Alan -- 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
