On 12/29/2015 5:24 PM, Or Gerlitz wrote:
On 12/29/2015 3:24 PM, Matan Barak wrote:
[...] We use a new firmware command in order to populate the GID table
and store the type along with the GID value.

Its a new value to existing command.. so better say we use a new value
to the SET_PORT firmware command to do X


Ok

Also here, break out mlx4_core new functionality e.g the changes to
include/linux/mlx4/cmd.h into mlx4_core only patch. You don't need any
change to mlx4_core to have it's own patch, I guess one up to three mlx4
core patches would be OK.


I'll split mlx4_core logically.

Did you make sure (at the resource tracker) that VFs can't do this new
set port command flavor?


In mlx4_common_set_port:
if (slave != dev->caps.function &&
    in_modifier != MLX4_SET_PORT_GENERAL &&
     in_modifier != MLX4_SET_PORT_GID_TABLE) {
        mlx4_warn(dev, "denying SET_PORT for slave:%d\n", slave);
        return -EINVAL;
}



Also find some spot to put blank line in the change-log, it's hard to
read this way.


No problem

Or.

Matan



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to