Andrew Morton <a...@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@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
