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: 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

  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