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/