[PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches

[Anderson, Trevor]

Keep it in please. We lurkers in the embedded community do use the per-port routing tables.
One of the problems with SRIO switch tables is that access to routes is not atomic; we can use
restricted access to per-port routing tables to reduce the risk of interference. And we still use
the Global table during enumeration.




> -----Original Message-----
> From: linuxppc-dev-bounces+tanderson=curtisswright.com at lists.ozlabs.org [mailto:linuxppc-dev-
> bounces+tanderson=curtisswright.com at lists.ozlabs.org] On Behalf Of Bounine, Alexandre
> Sent: Wednesday, September 15, 2010 8:31 AM
> To: Andrew Morton
> Cc: linux-kernel at vger.kernel.org; Thomas Moll; linuxppc-dev at lists.ozlabs.org
> Subject: RE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
>
> Andrew Morton <akpm at linux-foundation.org> wrote:
>
> > The handling of `table' is strange.  One would expect the caller of
> > this function to provide the correct table index, and for the caller
> to
> > increment that index at an appropriate time.
>
> Handling of the 'table' parameter is hardware-dependent.
> RIO switches (at least all that I know) have a per-port routing tables
> (RT)
> which can be configured independently. The 'table' parameter is expected
> to match
> to the port number (or broadcast if GLOBAL).
> The route set/get routines in this file use the standard route setting
> registers
> defined by RapidIO spec, but switches have internal mapping into an
> individual
> port RT or broadcast capability into all port RTs.
> Unfortunately, this HW design uses index 0 as a broadcast option that
> offsets
> per-port RT numbering by +1 (port 0 == table index 1, etc.).
>
> > So I take a look around but cannot find any means by which
> > ->add_entry() is called with anything other than RIO_GLOBAL_TABLE.
> > Maybe I missed something.  Is this all dead code?
>
> The current RIO enumeration uses only the global routing table concept.
> In the past, I had a temptation to remove the 'table' parameter and make
> RT settings simpler. But now I see scenarios when per-port routing
> tables
> may be configured by usermode apps. This capability may be implemented
> through sysfs attributes (probably I have to add them to make standard).
> Example: system that uses dual-port endpoints which can be enumerated by
> the host through one RIO port (management) and have individual routes
> configured for the second port (data path).
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries.  Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations.  The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.