Removal of pci_find_* in 2.5

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 :)

thanks,

greg k-h

I have several examples where the ordering of the PCI cards is critical to get stuff like boot device and primary controller detection right. pci_register_driver doesn't appear to have a good way to deal with this or have I missed something ?

From: Alan Cox <[email protected]>
Date: 13 Jul 2002 03:23:29 +0100

I have several examples where the ordering of the PCI cards is critical to get stuff like boot device and primary controller detection right. pci_register_driver doesn't appear to have a good way to deal with this or have I missed something ?

Cards get registered in the order they appear on the bus, or at least that is the way the algorithm worked the last time I looked.

Or, what other facility do you need?

For most cards that is all that has to be turned from a "happens to work" into a "officially this is what happens". I've replied about how to handle other stuff in an earlier message. Its not a big thing, and getting rid of most of pci_find_device will help. We still have people needing to find other devices so there are refcount/locking things to handle akin to what was done to make the old networking dev_get() type stuff actually DTRT

From: Alan Cox <[email protected]>
Date: 13 Jul 2002 15:46:55 +0100

We still have people needing to find other devices

In particular things like "if on PCI host controller DEV/ID, enable hw bug workaround foo". I'm going to need to do crap like this even in the TG3 driver, it has to be worked around in the TG3 driver code itself so this isn't a PCI black-list type thing where we swizzle bits in the PCI host controller registers.

That case shouldn't be a problem, since when your device get discovered, hopefully, the host controller is already there. Though in some cases, host controllers just appear as a sibling device, and in this specific case, it may be not have been "discovered" yet.

There can be other bad dependencies between "sibling" devices (especially functions of the same physical devices), which is why I would make sure that all devices on a given level have been probed (that is their pci_dev structure created) before the various drivers get notified.

Ben.

From: Benjamin Herrenschmidt <[email protected]>
Date: Sat, 13 Jul 2002 15:45:53 +0200

That case shouldn't be a problem, since when your device get discovered, hopefully, the host controller is already there. Though in some cases, host controllers just appear as a sibling device, and in this specific case, it may be not have been "discovered" yet.

THat's not what I'm concerned about, what I care about is that there still will be a pci_find_*() I can call to see if DEV/ID is on the bus. That is the easiest way to perform that search right now.

Yes, it will stay. It is needed for situations just like these, and lots of other valid reasons.

thanks,

greg k-h

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

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 like).

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 xxx_register_driver.

Eric

I don't think there is a good way for you to convert over to _register_driver(), that's the main reason I'm keeping the pci_find_* functions around, they are quite useful for lots of situations.

It doesn't sound like you are worrying about your device working in a pci hotplug system, and you would probably be willing do any pci device conversion work to the new driver model yourself, right? :)

thanks,

greg k-h

Assuming I can actually fit in better with the new driver model. As far as hot-plug. It is an abuse but I regularly hot-swap my rom chips in my development system.

I am probably looking at this from the wrong angle but my problem with current code base seems to be that I can only have one driver per pci device.

In any case I would like to have code that fits in nicely with the new driver system. I can take about one change in kernel API. For the most part the drivers are trivial, and having non-trivial maintenance for trivial code is less than ideal.

Eric

No, but you do do firmware, and you have a desire to tell the kernel about which devices are in the system from the firmware. The code path once you discover the device is exactly the same as if you were to actually plug in the device, or probe for it natively.

Though making legacy drivers hotpluggable seems absurd, the capability is actually a requirement for supporting many firmwares.

Don't most people? :)

We don't want to make things difficult. It's a PITA right now, since the documentation is lacking and not all the infrastructure is in place to really start plowing ahead. But, it will get better..

-pat

A clarification here. I am thinking of drivers/mtd/maps/ich2rom.c, or drivers/mtd/maps/amd766rom.c. (Should be in 2.4.19). What the driver do is find a pci bridge device behind which rom chips are usually found, and then it probes for a rom chip, behind the bridge.

Despite being LPC/ISA, there is a moderately standard way of getting a chip id from a rom chip (see drivers/mtd/chips/jedec_probe.c). Armed with the chip id I dynamically select the chip driver.

In practice my driver really is a driver for a subset of the bridge chip, allowing access to the rom chip. Besides giving a clue which addresses to probe the map driver also enables writes to the rom chip.

chip at address xxx for yyy bytes behind zzz. The challenging part is what structure the driver should really take. And for that I am asking for advice, or at least some ideas.

Well I want to keep the reminders coming of weird things that are actually supportable right now, and to ask for help in finding better ways to construct the drivers. If I could just do firmware my job would be so much easier :)

Eric