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 -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
