It was a hack (more a proof of concept where the problem was), and
Pavel Janik had some trouble with it (it hung before detecting the PCI
serial ports, while changing the link order worked fine - not sure why,
could this be a kernel stack overflow resulting from calling rs_init()
from within parport code instead of directly from the top level?).
My most recent patch simply moves parport_serial.c to a different
directory - that's why the patch is so big, but it doesn't otherwise
change a single line in that moved file (I split NetMos support to
the next patch, after this one is accepted and possible NetMos bugs
are resolved - works fine here with parport in polling mode, IRQ
sharing with serial ports not tested).
After the parport_serial.c move, the init order would be:
- parport
- serial
- parport_serial (needs both of the above initialized first)
- other char/block/net drivers (some of them might need the parallel
ports, including the PCI ones: lp, paride, plip - so moving all of
parport after char/block/net would be wrong)
> I'm happy to accept whichever patch is the better.
I'd suggest the more recent (larger, but not really...) one.
Thanks,
Marek
-
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/