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: Tue, 26 Oct 2010 16:22:52 +0200 [thread overview]
Message-ID: <4CC6E43C.8010104@neli.hopto.org> (raw)
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520147D879@CORPEXCH1.na.ads.idt.com>
Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>> I look at it this way: it prevents the need for another layer of
>> indirection: translating component tag to a destid.
>
> The destid alone is not enough. You will need an entire rio_dev object
> for that device anyway.
?? I did not say a rio_dev object is not needed; on the contrary, I do
have it.
In various parts of the enumeration and routing algorithm, it would need
to lookup the tag to find the destid, if the destid is in the tag then
this lookup is not needed.
> I think we are mixing two things together here. I understand your idea
> but do not see how it prevents me from having one common set of access
> coordinates for RIO devices (the starting point of our discussion).
I'm trying to argue we do not want redundant identification in the first
place unless absolutely necessary.
> Regardless of an implementation, having a way that ensures unified
> identification of switches by all processor boards is better than the
> current mainline implementation.
Well, we both know "the current mainline implementation" is easily
improved to unique identification I proposed. Therefore this statement
is misleading.
> Methods of forming a component tag may
> differ but still serve the same purpose. Personally I prefer to avoid
> any link of device identification to the destid because it may not be as
> intuitive as it seems for large systems with hot-plug. I will discuss
> this with some of RIO TWG guys to get their opinion on the best
> approach.
Please do, please elaborate: "may not be as intuitive" ... to what? for
implementation of ...?
> I will make a patch that defines fields of component tag, probably just
> one for now - identification field. This will ensure that any method
> used to assign component tag (id part of it) will be compatible with RIO
> spec part 8 error management.
Again slightly misleading information. Any unique identification
satisfies this requirement.
To prove my point: are you going to recycle the component tags as well
in case of hot-swaps, just like the destids?
> As for switch identification, at this moment I still prefer replacing
> rswitch->switchid with ID portion of the component tag because it is
> very simple and does not require changes to enumeration algorithm.
Yes, I agree switchid = tag, that's what I use also.
Micha
next prev parent reply other threads:[~2010-10-26 14:22 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
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 [this message]
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=4CC6E43C.8010104@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