Messages in this thread |  | | | Date | Sat, 07 Apr 2001 17:58:20 -0400 | | From | Jeff Garzik <> | | Subject | Re: Multi-function PCI devices |
| |
Linus Torvalds wrote: > It only means that you should probably approach it as being a special > "invisible PCI bridge", and basically have a specific driver for that > chip that acts as a _bridge_ driver. > > Writing a bridge driver is not that hard: your init routine will > instantiate the devices behind the bridge (ie you would allocate two > "struct pci_device" structures and you would add them to behind the > "bridge", and you would make _those_ look like real serial and parallell > devices. > > See for example drivers/pcmcia/cardbus.c: cb_alloc() for how to create a > new "pci_dev" (see the "for i = 0; i < fn ; i++)" loop: it creates the > devices for each subfunction found behind the cardbus bridge. It really > boils down to "dev = kmalloc(); initialize_dev(dev); pci_insert_dev(dev, > bus);").
Cool :) Creative and interesting solution.
IMHO that's a slippery slope... If you do this as a solution for multifunction devices, you also have to consider even more stupid hardware which exports one PCI function, but multiple BARs for different purposes...
Another problem, which I have yet to think much about, is doing a reverse mapping after what you just describe: how does one figure out that a bridge+devices is really a single hardware device? Answering that question is interesting for NICs as well, because 4-port NICs often appear as four devices behind a bridge. Some operations, such as sharing an EEPROM across four ports, or setting a special flag if you are quad-port hardware, require that knowledge. [ugly hacks exist now to get around our lack of such knowledge]
Jeff
-- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." - 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/
|  |