Re: [PATCH 1/6] staging: vme: allow explicit assignment of bus numbers

From: Martyn Welch
Date: Wed Aug 10 2011 - 08:50:25 EST

On 10/08/11 11:41, Manohar Vanga wrote:
> Hey Martyn,
>> I'm sorry, I'm still simply not convinced by this patch:
>> 1) For a single bus driver (i.e. in the situation where we have 2 bridges of
>> the same type), the numbering of the buses is still dependent on the order
>> that they are found in the scan.
> Yes this is still a bug. But this patch doesn't address this case.
>> 2) If the bridge drivers are loaded as modules, I have a feeling they will be
>> loaded sequentially and therefore the order of the bridges would only change
>> if the order of the loading of the drivers changed.
> And this is a major problem when it comes to multiple bridges of differing
> types. What I'm saying is that this patch simply fixes this one problematic
> case. We can move this out as soon as we have a more robust implementation.
> As of now however, I think applying this is useful as we have a decent
> workaround to the problem. If you want I can make the fact of it being
> applicable only to cases with differing bridges explicit in the commit
> message.

The problem is, I'm not convinced that this is the correct approach to take. I
think this should be parsed from sysfs dynamically (which may require some
work). I shall use the ethernet devices on my machine as an example:

I have 2 ethernet devices (and lo) on my machine:

$ ls /sys/class/net/
eth0 eth1 lo

These are symlinks and I can quite quickly find out which each of these
devices in (based on topology):
$ ls -l /sys/class/net/
total 0
lrwxrwxrwx 1 root root 0 2011-08-10 11:56 eth0 ->
lrwxrwxrwx 1 root root 0 2011-08-10 11:56 eth1 ->
lrwxrwxrwx 1 root root 0 2011-08-10 11:56 lo -> ../../devices/virtual/net/lo

I'd think that this contains the information that you have in the config file
(based on the previous discussion we had) and would allow you to map the bus
numbering after booting.

To do this, I think we need to register a class called "vme", I guess in
vme_init() and add a call to class_device_register in vme_register_bridge and
a call to class_device_unregister in vme_unregister_bridge.

Greg: Is that right?

I'm really not convinced that the solution presented in this patch is suitable
for inclusion upstream.


Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@xxxxxx | M2 3AB VAT:GB 927559189
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at