On Fri, Jan 14, 2000 at 03:57:48PM -0500, Theodore Y. Ts'o wrote:
> 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.
My second patch sent to you does exactly this. It also checks that there
is only one PCI i/o region on the card. This should be quite safe,
though I can imagine there could be boards that'd crash ...
Perhaps we could also ignore cards that return the prog-if equal to 0
(8250, unlikely on a PCI card), or only accept those saying they're
16450/16550 (prog-if 1 and 2). This would eliminate most of false
positives. My current code checks for a 'reasonable' prog-if <= 6. See
recent pci.ids for more info.
> 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.
Perhaps Martin could comment?
> 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.
This sounds very good. I'd put it in an #ifdef, but try to leave it
enabled for a while in the development kernel series, to see if it
causes any trouble or not ... if yes, well, there still are the correct
entries for the 3Com modems now. At least some enhancement.
> Sigh.... PC hardware is sh*t.
Yes, it is. And what's worse, new technologies (PCI, USB, ...) don't
make it better. For example many USB devices don't behave as they should ...
Unrelated, I'm writing the USB ACM (modem) driver and I'd like to ask if
there is any documentation on writing a tty driver besides the code and
includes? I think I got it all right, but I may be wrong. I still have
trouble with tty_hangup - it seems not to do anything when called from
my code.
Also many serial drivers seem to add tty_hangup to tq_sched, when
tty_hangup adds tty_do_hangup to tq_sched too, thus resulting in this
being done twice. Is that intended? I doubt so ...
-- Vojtech Pavlik SuSE Labs- 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 : Sat Jan 15 2000 - 21:00:25 EST