Pre 18 the call path is do_basic_setup() -> device_setup() ->
chr_dev_setup() -> tty_init() -> rs_init().
In 2.4.x rs_init is entered with the module_init() (__initcall) magic.
The attached is for 2.2.20, and simply removes the tty_init() ->
rs_init() path. This mimics 2.4.x.
There might be an issue; do_initcalls() is slightly later in
do_basic_setup() than device_setup(), but the in between code looks
similar to 2.4.x kernels so I don't think it's a problem delaying the
serial init.
I'll post the slightly less elegant hack to the serial driver that
compensates for the broken kernels shortly.
Patch status is: Works For Me. Testers needed.
..Stu
----
diff -ru linux-2.2.20/drivers/char/tty_io.c
linux-2.2.20-serial-init-fix/drivers/char/tty_io.c
--- linux-2.2.20/drivers/char/tty_io.c Fri Nov 2 11:39:06 2001
+++ linux-2.2.20-serial-init-fix/drivers/char/tty_io.c Mon Nov 5 22:03:54
2001
@@ -2189,9 +2189,6 @@
#ifdef CONFIG_ESPSERIAL /* init ESP before rs, so rs doesn't see the port
*/
espserial_init();
#endif
-#ifdef CONFIG_SERIAL
- rs_init();
-#endif
#ifdef CONFIG_COMPUTONE
ip2_init();
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/