Re: [RFC] PCI bridge driver rewrite

[Greg KH]

On Thu, Feb 24, 2005 at 01:22:01AM -0500, Adam Belay wrote:
> Hi all,
> 
> For the past couple weeks I have been reorganizing the PCI subsystem to
> better utilize the driver model.  Specifically, the bus detection code
> is now using a standard PCI driver.  It turns out to be a major
> undertaking, as the PCI probing code is closely tied into a lot of other
> PCI components, and is spread throughout various architecture specific
> areas.  I'm hoping that these changes will allow for a much cleaner and
> more functional PCI implementation.
> 
> The basic flow of the new code is as follows:
> 1.) A standard "driver core" driver binds to a bridge device.
> 2.) When "*probe" is called it sets up the hardware and allocates a
> "struct pci_bus".
> 3.) The "struct pci_bus" is filled with information about the detected
> bridge.
> 4.) The driver then registers the "struct pci_bus" with the PCI Bus
> Class.
> 5.) The PCI Bus Class makes the bridge available to sysfs.
> 6.) It then detects hardware attached to the bridge.
> 7.) Each new PCI bridge device is registered with the driver model.
> 8.) All remaining PCI devices are registered with the driver model.
> 
> Steps 7 and 8 allow for better resource management.
> 
> 
> I've attached an early version of my code.  It has most of the new PCI
> bus class registration code in place, and an early implementation of the
> PCI-to-PCI bridge driver.  The following remains to be done:
> 
> 1.) refine and cleanup the new PCI Bus API
> 2.) export the new API in "linux/pci.h", and cleanup any users of the
> old code.
> 3.) fix every PCI hotplug driver.
> 4.) write a bridge driver for the PCI root bridge
> 5.) write a bridge driver for Cardbus hardware
> 6.) refine device registration order
> 7.) redesign PCI bus number assignment and support bus renumbering
> 8.) redesign PCI resource management to be compatible with the new code
> 9.) testing on various architectures
> 10.) Write "*suspend" and "*resume" routines for PCI bridges.  Any ideas
> on what needs to be done?
> 11.) fix "PCI_LEGACY" (I may have broke it, but it should be trivial)
> 
> I look forward to any comments or suggestions.

I like it all :)

If you want to submit patches now that rearrange the code to make it
easier for you to modify in the future to achieve the above goals, feel
free, I'll gladly take them.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/