linux-kernel

Open Source and information security mailing list archives

Date:	Thu, 31 Jan 2008 10:35:25 -0800
From:	Phil Terry <pterry@...romemory.com>
To:	Wei.Zhang@...escale.com
Cc:	Kumar Gala <galak@...nel.crashing.org>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH 4/6] Add multi mport support.

On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote:
>  
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@...nel.crashing.org] 
> > 
> > On Jan 31, 2008, at 12:15 AM, Kumar Gala wrote:
> > 
> > >
> > > On Jan 30, 2008, at 11:57 PM, Zhang Wei wrote:
> > >
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Kumar Gala [mailto:galak@...nel.crashing.org]
> > >>>
> > >>> On Jan 30, 2008, at 4:30 AM, Zhang Wei wrote:
> > >>>
> > >>>> Change lots of static variable to mport private. And add
> > >>> mport to some
> > >>>> function declaration.
> > >>>
> > >>> Can you explain this patch further.  Its not clear 
> > exactly from this
> > >>> commit message why we are doing this.
> > >>>
> > >>> - k
> > >>
> > >> Sorry about I have a little hurry about it.
> > >>
> > >> The original RapidIO driver suppose there is only one mpc85xx RIO
> > >> controller
> > >> in system. So, some data structures are defined as mpc85xx_rio  
> > >> global,
> > >> such as 'regs_win', 'dbell_ring', 'msg_tx_ring'. Now, I 
> > changed them
> > >> to
> > >> mport's private members. And you can define multi RIO 
> > OF-nodes in dts
> > >> file
> > >> for multi RapidIO controller in one processor, such as PCI/PCI-Ex  
> > >> host
> > >> controllers
> > >> in Freescale's silicon. And the mport operation function 
> > declaration
> > >> should be changed
> > >> to know which RapidIO controller is target.
> > >
> > > thanks, this makes a lot of sense and now reviewing the patch will
> > > make some sense to me :)
> > 
> > when we have multiple ports are the device IDs on the ports intended  
> > to be unique only to a port or unique across all ports?
> > 
> I consider each RIO controller will has its own network, the device IDs
> should be
> unique only in its port network.
Hmmm, I see two cases:

1. I have two mport to two controllers each connected to different
physical fabrics. This system can act as an application bridge between
the two fabrics.

2. I have two mports to two controllers each connected directly or
indirectly to the same fabric. I want to use the extra bandwidth and
load balance and/or have a fall back redundant connection via an
alternate physical connection to the fabric etc.

What should be the rules for allocating the initial IDs to the two
mports to allow system wide enumeration to work in both of the above
cases? 

What do you expect the semantics of higher level addressing to be:
 a pair <mport,id>, where <x,n> is a different device from <y,n>,
 a pair <mport,id>, where <x,n> is the same device as <y,n>,or
 a singleton n, where n is unique and identifies the first routing step
of which controller, x or y, to use.

I smell a can of worms.... :-)

Cheers
Phil

> 
> Cheers!
> Wei
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@...abs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives