public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Mon, 25 Oct 2010 22:06:44 +0200	[thread overview]
Message-ID: <4CC5E354.80009@neli.hopto.org> (raw)
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520147D5C2@CORPEXCH1.na.ads.idt.com>

Bounine, Alexandre wrote:
> Micha Nelissen <micha@neli.hopto.org> wrote:
>> that switch. The tag uses one extra bit to identify the device as a
>> switch instead of an endpoint. This provides the information to
>> unambiguously identify a switch from an endpoint.
> 
> OK taking away #2. But do not see how it justifies storing two values of
> destid.

I look at it this way: it prevents the need for another layer of 
indirection: translating component tag to a destid.

> And you have just confirmed using CT for unique identification. 

That's correct, but I never said (intended to say) I didn't.

> We
> simply have differences in interpretation of CT: you are using component
> tag to pass unique identification and I am using CT as a unique
> identification. I prefer not to assume any relationship between routing
> information and the component tag.

Why no relation? My experience is that during debugging it's useful to 
have the destid directly at hand, it's just very practical. (Otherwise 
any drawing of a random network would need two "identification" numbers 
per drawn node: the component tag (true identification), and destid 
since that's what everyone uses to identify a device, what needs to 
programmed into the LUTs of a switch, identification in sysfs, etc.).

Micha

  reply	other threads:[~2010-10-25 20:07 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 [this message]
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=4CC5E354.80009@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