Date: Fri, 14 Jan 2000 20:37:03 +0100
From: Vojtech Pavlik <vojtech@suse.cz>
I have made a patch that allows the serial.c driver detect 3Com 56k PCI
modems.
However, because I think that adding an entry to the database for every
conceivable PCI modem or serial port is wrong, I've also added support
for generic PCI serial boards, that report the correct PCI class and
programming inerface. This is why the 3Com modem support is #if0ed out -
the generic support is enough for the 3Com modems.
I'm leaving it up to you which way will you choose - either just
expanding the table or also adding the generic support. The generic
support might cause some false positives, though I think the serial port
detection code will eliminate those out.
I agree with you that I don't like the hard-coded table.
The problem is that most of the PCI cards listed in the table
self-identify as a "generic PCI serial board". Worse yet, some of the
lock up the system if you guess wrong.... (This is true more for I/O
memory mapped boards than I/O port boards, mercifully.)
I can try to add some hueristics which avoid the worst case scenarios
--- you can't always assume that region 0 is an I/O port, for example,
and looking for the first region which is an I/O port *should* be safe.
On the other hand, if people start sending me hate mail that the
autodetection is causing their system to lock up, we'll have to take it
out.
The other reason why up until now I hadn't bothered with hueristics is
that with the exception of the 3COM 5610 modem, nearly all of the boards
that I've received for testing have been multiport board, and I haven't
been able to determine a generic way of determining how many ports a
multiport serial board might have --- and where they are located. (Some
boards locate each port on a separate PCI I/O region, other boards put
all of the ports in a single I/O region, and space them 8 ports apart,
except for those 0x200 apart, for no good reason....)
If someone has access to the PCI specifications, and can tell me whether
(at least in some standards fantasyland) there's a reliable way of
finding out that information, that would be useful. Until then, the
hard-coded table is going to be safer, so any kind of hueristics is
going to have to be under a #ifdef, so we can remove it easily if it
locks up people's systems.
Sigh.... PC hardware is sh*t.
- 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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:12 EST