Messages in this thread | | | Date | Fri, 10 Apr 1998 16:32:21 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Re: 2.1.93.. |
| |
From: Martin Mares <mj@atrey.karlin.mff.cuni.cz> Date: Fri, 10 Apr 1998 16:20:17 +0200
The BIOS probe order is different from machine to machine or even from BIOS release to BIOS release. The new PCI subsystem now always sorts the devices by bus/device/function lexicographically, so you get the same order not depending on whether you use the BIOS or not. The latest PCI patch I've sent to the list adds an option to reverse the order to be compatible with 2.0.X.
It's probably time for public discussion on this issue...
I do not find pci=reverse to be an acceptable solution.
In order to correctly choose the boot host adapter in system with multiple PCI BusLogic MultiMaster host adapters, I use the same algorithm BusLogic's BIOS does to decide on the device recognition order. On BT-946C/956C/956CD boards and on BT-948/958/958D boards where the AutoSCSI option "Use Bus And Device # For PCI Scanning Seq." is turned off, this requires that the driver be able to determine the precise order as enumerated by the motherboard's PCI BIOS. There are a significant number of motherboard's whose PCI BIOS use the opposite order from the kernel's new fixed order, or a variant thereof, and the recent kernel change now *requires* a command line option for proper operation where one was not necessary before. I find this an unacceptable burden to place on end users.
I believe I've shown that I have a legitimate need for access to pcibios_find_device or equivalent for the MultiMaster probe, and according to my discussions with Mylex the upcoming DAC960 driver will have precisely the same problem. I have spent substantial effort in the BusLogic driver to recognize boards in the correct order, and I believe this effort is justified.
I think the simplest solution would be to add a new call that allows one to iterate using the BIOS order where necessary, but then returns the PCI_Device struct rather than the individual bus/device/function numbers as previously.
Leonard
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |