Messages in this thread | | | Date | Fri, 22 Oct 2010 20:28:46 +0200 | From | Micha Nelissen <> | Subject | Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches |
| |
Bounine, Alexandre wrote: > Micha Nelissen <micha@neli.hopto.org> wrote: >> Alexandre Bounine wrote: >> How can you say this? The two variables have different meanings, this >> logically implies you can't merge them. So how do you say 'this does > not >> prevent us from ...' without providing a reason? > > Looks like I formulated it bad - better would be: they have different > interpretation by hardware but logically in RapidIO they have single > role - destid/hopcount are a device coordinates in the RIO network used > to access that device.
They are logically different as well (for a non-host).
rswitch->destid with hopcount is the way to reach that switch.
rswitch->rdev->destid should be the id associated with a given switch, so that every (processor) device can agree what id some switch has. For a non-host, the path to reach a switch may use a different id than the switch itself has; it's just the id by which it was discovered.
However, it's possible to fix that by fixing the id+hopcount once the switch is found using the path with its own id: then you know the right hopcount.
>> can be defined to point to the switch that a given rio_dev is > connected >> to. This is useful for quick lookups. How else can to know to which >> switch a given device is connected? > > rdev->rswitch is not a pointer to the entire switch device object - it > is a pointer to the switch specific extension associated with given > rio_dev (if applicable). There is no other role for rdev->rswitch.
I know this, it doesn't answer my question.
> Why would you keep a pointer to device data extension instead of the > pointer to attached device object itself?
There is no particular reason, but this is a useful way to define the fields that are there.
My point is, now that you remove the pointer field, that information (to which switch is a particular device connected) cannot be stored in this way, so do you have an alternative proposal for that? Maybe add a new field.
> BTW, I have back and forward links added in previous patches and only > one link that may be added later is a forward link from mport to the > attached rio_dev (ptr to rio_switch will not work here because it can be > switchless connection). But this reference has to be added into > rio_mport.
Possible, but I suggest to put it in the rio_net: fields rdev_host, and rdev_self. You can see it in the patch I sent you.
Micha
| |