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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
