[lkml]   [2010]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [PATCH v2 09/10] RapidIO: Add support for IDT CPS Gen2 switches
    Andrew Morton <> 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
    > 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
    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
    defined by RapidIO spec, but switches have internal mapping into an
    port RT or broadcast capability into all port RTs.
    Unfortunately, this HW design uses index 0 as a broadcast option that
    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
    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).

     \ /
      Last update: 2010-09-15 17:35    [W:0.023 / U:18.432 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site