On Thu, Jan 26, 2006 at 04:14:44PM -0800, John Klingler wrote:
Unfortunately I'm under NDA for the vendor's code, except for our
parts of it, of course. I'm unsure why they have an NDA, they give
the drivers to OEMs who use their hardware. Just SOP I guess.
Sorry, but I can't help with non-GPL code like this :(
Actually, I don't think you will be able to write a non-GPL driver to be
able to do this for the 2.6 kernel, due to all of the api changes. What
it sounds like is you really just want to hook into the pci hotplug
system, as then your driver will work with all of the existing pci
hotplug userspace tools.
Anyway, the kernel's core pci bus probe will not be able to "see"
beyond the fabric bridge, just the bridge card itself:
08:01.0 Bridge: Stargen Inc. SG2010 PCI to Starfabric Gateway
It would have to use the methods the driver supplies to pci_register_driver,
and pci_proc_attach_device and pci_enable_device in the pci_driver struct.
Perhaps it would be easier to show you the modules file for the drivers
in our stack responsible for the kernel interface. I've only included the
relevant dependencies.
pci_add_new_bus
pci_bus_assign_resources
pci_enable_device
pci_mem_start
pci_proc_attach_device
pci_proc_detach_bus
pci_root_buses
pci_scan_slot
pci_set_master
Looking at the above list, I notice a few asymmetries. pci_add_new_bus is
called but not pci_proc_attach_bus. pci_proc_attach_device is called but
not pci_proc_detach_device when the driver is unloaded. Perhaps you can
see a call that should be made.
Without the code itself, I do not think so, sorry.
A prime suspect is enhanced error checking in 2.6. For example, the buses
added by the drivers have no parent. While this wasn't a problem in 2.4,
the 2.6 kernel may reject that.
No, root busses have no parent and work just fine :)
good luck,
greg k-h
