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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 1 Feb 2008 12:06:26 +0800
From:	"Zhang Wei" <Wei.Zhang@...escale.com>
To:	<pterry@...tro.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.

Hi, Phil,

> -----Original Message-----
> From: Phil Terry [mailto:pterry@...romemory.com] 
> 
> On Thu, 2008-01-31 at 14:30 +0800, Zhang Wei wrote:
> >  
> > > >
> > 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:

Good questions! They are very important and also my concern now.

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

The current driver just looks two mport as two independent fabrics.
We can add bridge driver to implement your idea.

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

That's a terrible thing in the current driver. Two mports get the same
 ID in one fabric. About the port bound, it's a good idea, I also need
 a new driver to support it.

In fact, our first mission is to make the RapidIO driver ported from ppc
to powerpc can
 be compiled and run. Fortunately, there is no more than one port in
processor now,
 we have time to implement it.

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

A choice is add ID option into dts node. I have some ideas about RapidIO
 driver in u-boot. U-boot can assign ID in dts and tell kernel.

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

It seems the address pair is a must-be selection as pci bus.
But now, no connection between ports. Every operations in only
 in its own port view.

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

A good nose! Thanks! :)

Cheers!
Wei
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ