Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 15 Oct 1999 09:52:19 -0400 | Subject | Re: serial.c patch in 2.3.19 | From | tytso@mit ... |
| |
Date: Thu, 14 Oct 1999 21:35:36 +0200 From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Do you know who added the following patch in 2.3.19 and what its purpose is?
It's breaking systems and HOWTO's. It's getting difficult to convince serial.c to give up its lock on the ioregion if one has another driver that also drives 8250 style serial ports (such as baycom_ser_*).
This patch only causes the serial driver to only release the ioregion if it had requested it in the first place.
I don't see how this would be breaking systems. Basically, this patch causes the serial driver to not release the ioregion if the UART is unknown. But if the UART is unknown, the region wouldn't have been requested by the serial driver.
setserial /dev/ttySx port 0 seems to be the only way to convince serial to give up a particular port.
It has always been the case that if the serial port is non-zero and the UART is set to some value, the serial driver will grab the IO region.
From the point of view of the serial driver, the baycom driver is an interloper that's trying to take over the port. If it that's the case, you have to configure the serial driver not to try to use the port by using setserial.
If you have two drivers trying to use the same port range, the first one to grab the I/O range is going to win. Why should this be surprising?
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |