On Wed, Dec 27, 2017 at 5:27 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
> On 12/24/2017 4:00 PM, Or Gerlitz wrote:
>>> @@ -5531,6 +5533,7 @@ struct mlx5_ifc_init_hca_in_bits {
>>> u8 op_mod[0x10];
>>>
>>> u8 reserved_at_40[0x40];
>>> + u8 sw_owner_id[4][0x20];
>>> };
>> can we do here just a plane addition of bits? don't have the code
>> infront of me, but seems suspicious
> I don't understand what you are asking. This is what the tool generated.
Dan, the tool is serving us and not the other way around, so
before your changes we had:
struct mlx5_ifc_init_hca_in_bits {
u8 opcode[0x10];
u8 reserved_at_10[0x10];
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
u8 reserved_at_40[0x40];
};
and now we have a struct which is 128b bigger
but is used for the same FW command
struct mlx5_ifc_init_hca_in_bits {
u8 opcode[0x10];
u8 reserved_at_10[0x10];
u8 reserved_at_20[0x10];
u8 op_mod[0x10];
u8 reserved_at_40[0x40];
u8 sw_owner_id[16][0x8];
};
my question is if/why this is legal. Maybe I am wrong, but
I don't think we can just go and change the size of the inbox
payload for a command. Maybe there's another (silent) reserved
space which is not present in the original form of the struct?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
