Re: [RFC] PCI bridge driver rewrite

[Adam Belay]

On Thu, 2005-02-24 at 02:25 -0500, Jon Smirl wrote: 
> When you start writing the PCI root bridge driver you'll run into the
> AGP drivers that are already attached to the bridge. I was surprised
> by this since I expected AGP to be attached to the AGP bridge but now
> I learned that it is a root bridge function.

I'm going to have the PCI root bridge driver bind to a device on the
primary side of the bridge.  The device could be enumerated by ACPI or
created manually when the bridge is detected.  It will not, however, be
a PCI device.

> 
> An ISA LPC bridge driver would be nice too. It would let you turn off
> serial ports, etc and let other systems know how many ports there are.
> No real need for this, just a nice toy.

I think this would make a lot of sense.  ACPI could be used to enumerate
child devices for this bridge.  I'd like to begin work on a generic ISA
bus driver soon.

> 
> Does this work to cause a probe based on PCI class?
> static struct pci_device_id p2p_id_tbl[] = {
>        { PCI_DEVICE_CLASS(PCI_CLASS_BRIDGE_PCI << 8, 0xffff00) },
>        { 0 },
> };

Yes, the macro is used when matching against only a class of device.

> 
> I would like to install a driver that gets called whenever new
> CLASS_VGA hardware shows up via hotplug. It won't attach to the
> device, it will just add some sysfs attributes. The framebuffer
> drivers need to attach the device. If I add attributes this way how
> can I remove them?

It would be possible, but probably not a clean solution.  Ideally we
want one driver to bind to the graphics controller and remain bound.  It
will then create class devices for each graphics subsystem, such as
framebuffer.  Much work remains to be done before this can happen.

Thanks,
Adam


-
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/