[lkml]   [2002]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Removal of pci_find_* in 2.5
Greg KH <> writes:

> Hi all,
> Well, I've been trying to figure out a way to remove the existing
> pci_find_device(), and other pci_find_* functions from the 2.5 kernel
> without hurting to many things (well, things that people care about.)
> Turns out these are very useful functions, outside of the "old" pci
> framework, and I can't really justify removing them, so they are staying
> for now (or until someone else can think of a replacement...)
> The main reason for wanting to do this, is that any PCI driver that
> relies on using pci_find_* to locate a device to control, will not work
> with the existing PCI hotplug code. Moving forward, those drivers will
> also not work with the driverfs, struct driver, or the device naming
> code.
> So if you own a PCI driver that does not conform to the "new" PCI api
> (using pci_register_driver() and friends) consider yourself warned.
> Your driver will NOT inherit any of the upcoming changes to the drivers
> tree, which might cause them to break. Also remember, all of the people
> that are buying hotplug PCI systems for their datacenters will not buy
> your cards :)

I do but it only doesn't use pci_register_driver because that doesn't

The driver is a mtd map driver. It knows there is a rom chip behind
a pci->isa bridge. And it needs to find the pci->isa bridge to
properly set it up to access the rom chip (enable writes and the

It isn't a driver for the pci->isa bridge, (I'm not even certain we
have a good model for that). So it does not use pci_register_driver.

If you can give me a good proposal for how to accomplish that kind of
functionality I would be happy to use the appropriate

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.113 / U:64.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site