While playing around with the serial driver, I noticed some oddities:
1. You could generate an oops by passing an alphabetic irq to setserial (this
is technically a bug in setserial too, it just uses sscanf with no error
checking). When given an alphabetic string for a %d, sscanf gives you some
crazy negative number, which the serial driver just went and used to index
into IRQ_ports. BOOM! Oops while in process setserial.
2. You could set the IRQ to anything if you had CAP_SYS_ADMIN. Of course,
request_irq failed, but I was noticing system hangs in some cases (like trying
to change the IRQ to something sane) when the serial driver thought the IRQ
was something taken by another device. I changed the behavior to return the
appropriate error code instead.
3. auto_irq wasn't being listened to when called from setserial. I changed
this, but it seems that detect_uart_irq still doesn't work, at least on my
system. I'm suspecting it might be my hardware, because I compared this
routine with a DOS one I found, and they seemed equivalent (but then again,
what the hell do I know about DOS? ;).
4. detect_uart_irq returns zero on failure, but this is checked nowhere, as a
result, if you did manage to autoconfigure and call this function, if it
failed, your serial IRQ was set to the timer!
The patch to fix all these (execpt detect_uart_irq's failure to detect) is
attached.
P.S. On an unrelated note, does anyone know why the latest ISDN code isn't in
2.4 yet? It'd be nice to be able have US NI1 support without std2kern'ing
the isdn cvs tree..
-- Mike Perry http://got.fscked.org?
- 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 Jul 23 2000 - 21:00:20 EST