Hi Martyn, > I assume this is in a system where there are more than one type of bridge > (i.e. a ca91c042 and tsi148). Yes. This is referring to multiple bridges on a single PCI bus (in the case of the existing bridges). In practice we have only a single bridge of a single type. We can however have multiple types of bridges (eg. 1 TSI148 and 1 Universe). This solution is specifically for such situations. > I'm not sure that passing a list of bus numbers to each driver is the correct > way to resolve this. This issue also exists for hard drives and ethernet > devices as well. This solution won't help the cases where multiple bridges of the same type are present (as we cannot control probe order) however in the case of multiple bridges of differing types, it helps in deterministically assigning numbers to the bridge. The array was created simply for the reason that the code allows for multiple bridges of the same kind. In practice we have only one of a specific kind. > The network subsystem either has or uses a mechanism to allow udev rules to > rename the devices (this seems to be done by MAC address on my system). > > I believe drive ordering is resolved to some extent with UUIDs. Persistent > device naming can be provided by using udev rules to create symlinks (such as > "/dev/cdrom" etc), with the drives are determined by system topology. > > I'm wondering whether re-ordering the bus numbering based on system topology > using udev rules (where persistent bus numbering is required), or bind based > on system topology and not need persistent numbering at all). The problem here is that it is kernel space that requires a consistent numbering so creating symlinks is not a useful solution for this. (unless the driver loader script queries each device for its UUID at startup which seems a little like a roundabout way). The VME drivers require a list of bus numbers that it passes to the VME driver so it knows which buses/bridges to probe on. We need to pass this to the drivers during load time. Are you recommending we change this to UUID's? Also, if we replace a card entirely (eg. in the case of a malfunction), the UUID changes and we need to update a lot of local files to maintain the automated startup (Please correct me if I'm wrong here). This would become a mess to maintain really quickly. In this patch, we don't solve the issue of multiple bridges of the same kind but we solve the automation issue in cases of different types of bridge. We already maintain a database with configuration options for each crate and a bus number can be easily added. This won't change in the case of card replacement. -- /manohar _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel