From: Micha Nelissen <micha@neli.hopto.org>
To: "Bounine, Alexandre" <Alexandre.Bounine@idt.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
Matt Porter <mporter@kernel.crashing.org>,
Li Yang <leoli@freescale.com>,
Kumar Gala <galak@kernel.crashing.org>,
Thomas Moll <thomas.moll@sysgo.com>
Subject: Re: [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches
Date: Fri, 22 Oct 2010 23:58:59 +0200 [thread overview]
Message-ID: <4CC20923.8050400@neli.hopto.org> (raw)
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E55201445A6B@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>> rswitch->rdev->destid should be the id associated with a given switch,
>> so that every (processor) device can agree what id some switch has.
>
> If we will need to identify the same physical switch by different
> processors we may use the component tag which now is unique for every
> device.
Yes, identification is the point. I think it might be confusing to have
a destid *and* a component tag id which are slightly different. The
destid is unambiguous (if you know whether the device is a switch or
endpoint) so I think it makes sense to use that if possible.
> This actually gives me another idea: instead of using global
> next_switchid counter make rswitch->switchid = component_tag and
> switches in sysfs will look identical for every processor (or just get
> rid of rswitch->switchid and use component_tag directly for switches).
I still prefer the destid as the single identification id.
Micha
next prev parent reply other threads:[~2010-10-22 21:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-21 19:10 [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches Alexandre Bounine
2010-10-21 19:10 ` [PATCH -mm 1/2] RapidIO: Use common destid storage for endpoints and switches Alexandre Bounine
2010-10-21 19:10 ` [PATCH -mm 2/2] RapidIO: Integrate rio_switch into rio_dev Alexandre Bounine
2010-10-21 21:15 ` [PATCH -mm 0/2] RapidIO: Changes to handling of RIO switches Micha Nelissen
2010-10-22 16:47 ` Bounine, Alexandre
2010-10-22 18:28 ` Micha Nelissen
2010-10-22 21:04 ` Bounine, Alexandre
2010-10-22 21:58 ` Micha Nelissen [this message]
2010-10-25 13:22 ` Bounine, Alexandre
2010-10-25 16:13 ` Micha Nelissen
2010-10-25 17:13 ` Bounine, Alexandre
2010-10-25 20:06 ` Micha Nelissen
2010-10-26 13:39 ` Bounine, Alexandre
2010-10-26 14:22 ` Micha Nelissen
2010-10-26 17:17 ` Bounine, Alexandre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CC20923.8050400@neli.hopto.org \
--to=micha@neli.hopto.org \
--cc=Alexandre.Bounine@idt.com \
--cc=akpm@linux-foundation.org \
--cc=galak@kernel.crashing.org \
--cc=leoli@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mporter@kernel.crashing.org \
--cc=thomas.moll@sysgo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox