[ofw] [PATCH] ib/mad: fix routing of vendor mads

[Sean Hefty]

>While this fix will work for now, it seems short sighted and incorrect
>to enhance the core drivers with vendor specific MAD case statements.
>Instead it would seem more appropriate for the HCA driver to register
>with the core as being interested in the appropriate list of classes.
>This way future extensions to any driver or new special MAD processing
>in drivers can be supported without any core driver enhancements.

The change on the receive processing only looks at the method to
determine how the mad should be routed.  The change on the send side
adds the method check, plus fixes the routing for vendor mads that are
*not* associated with the HCA driver (which matches the existing code
for receive handling).  The current code assumes all vendor mads belong
to the HCA driver.

I personally would not recommend that any lower level driver call into
an interface exported by a filter driver.  That just makes for a pnp
handling nightmare.

Always letting the HCA driver process the MADs, similar to the linux
code, makes sense.  But MAD handling in the HCA driver is done
synchronously, and not all calls into the MAD layer are blockable.
Probably the best you could do is add a new 'do_you_want_this_mad()'
call to ci_interface_t that returned whether the HCA wanted the MAD or
not, but did not process the MAD.

The HCA drivers would need to be updated to implement the call.  I don't
know if having checks duplicated in the HCA drivers makes the code more
or less maintainable than what's there today.  (And, really, the
do_you_want_this_mad() call would be the same for both mthca and mlx
drivers.)  Do the HCA drivers check only vendor mads, or also
performance/baseboard management mads?  What about SMPs?  I don't think
that you'd want to split the functionality between drivers, and from a
generic view, we don't know what functionality an arbitrary HCA driver
may have implemented.  Moving all of the checks into the HCA drivers is
a significant change - basically everywhere that ROUTE_LOCAL appears in
the code should be removed, with those checks pushed down.

- Sean