Re: [PATCH 2/8] staging: vme: allow explicit assignment of busnumbers

[Manohar Vanga]

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