> 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.
Consider this course of action:
setserial /dev/ttySx uart none
resource not released
setserial /dev/ttySx port 0
resource still not released
(tried as of 2.3.20)
The AX25-HOWTO instructs people to use
setserial /dev/ttySx uart none to make serial
release a port before using another driver
for that port, that's why it's breaking systems.
> >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.
That's what people are using and now breaks.
> 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?
THIS is not the surprise. THe surprise is that
setserial /dev/ttySx uart none no longer makes serial give up the port.
Tom
-
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/