Re: [benet] possible endianness bug in be_cmd_txq_create()

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, Dec 10, 2017 at 06:43:08PM +0000, Al Viro wrote:
> On Sun, Dec 10, 2017 at 04:41:20PM +0000, Al Viro wrote:
> 
> > I don't have the hardware, so the above is completely untested (caught by
> > sparse when trying to do endianness annotations in drivers/net), but it
> > does look like it might be worth a look from benet maintainers.
> 
> Another very fishy place is be_roce_mcc_cmd().

be_get_fw_log_level()/be_set_fw_log_level() look slightly fishy as well:
the latter has
                        if (cfgs->module[i].trace_lvl[j].mode == MODE_UART)
                                cfgs->module[i].trace_lvl[j].dbg_lvl =
                                                        cpu_to_le32(level);
while the former
                        if (cfgs->module[0].trace_lvl[j].mode == MODE_UART)
                                level = cfgs->module[0].trace_lvl[j].dbg_lvl;
and returns level without further conversions.  The caller of be_cmd_set_...()
pass a host-endian value as level (48 or 64); the caller of be_cmd_get_...()
expect a host-endian return value - it compares the result with 48.

There's almost certainly a missing conversion somewhere; at a guess -
le32_to_cpu() on the be_cmd_get_...() side.