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

[Bounine, Alexandre]

Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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).


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