Hi everyone,
Individual Computers is basically a single-man company, which
manufacturers some boards for old Amiga and C64 enthusiasts. There are a
few hundred of these boards in circulation.
The board I have, the Catweasel Mk4, has PCI ID e159:0001. (This
unfortunately belongs to TigerJet 300 ISDN device, because the
Individual Computers is not registered.) It has ports for things like
Amiga mice and keyboards, and I'm guessing these may be serial in
nature. Whatever the reason, it classes itself as a serial
communications controller.
I have a custom driver for this hardware, which used to work some half a
year ago, probably on 2.6.20. It seems that with 2.6.22, the custom
driver does not probe the Catweasel card any longer. Upon investigation,
I found out that the serial driver has claimed it: it contains a
guessing logic that will claim almost any serial communications
controller for itself.
I'm looking for a way to make serial driver give that one device up.
Which one of these solutions would seem most acceptable, on the level
that a small patch could be placed in 8250_pci.c or elsewhere:
1) during generic probe, immediately return if the dev->vendor ==
PCI_VENDOR_ID_TIGERJET and dev->device == PCI_VENDOR_ID_TIGERJET_300
with comment that explains that this really targets Individual
Computer's Catweasel line of cards. There should be no harm to TigerJet
300 because it is an ISDN device with its own driver.
2) have a kernel commandline option or module option that says "do not
attempt generic serial probe on this system". This could be defensible
on the grounds that generic probes can't always work, so there should be
a way to fix things up when they don't.
3) Some userland way to make the driver give up particular device. Rmmod
doesn't work for me, because the driver is linked in the kernel on
Ubuntu G, but if there could be a way to somehow deregister the driver,
that could be quite useful to me. Blacklisting? Command line parameter
to tell kernel to skip "serial" driver completely? Anything at all?
As possibility 3) implies, I can live without the serial driver. I'm
unfortunately somewhat ignorant about available ways to accomplish this.
3) also results in a side question: how does the kernel resolve
situations where two drivers look capable of driving the same hardware?
Does it priorize the drivers by insertion order, alphabetic sorting by
name, or by most specific match in the pci id table, or any other
explicit rule like that which I could exploit?
With regards,
Antti
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
