From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: [RFC] weirdness in cxgb3_main.c:init_tp_parity()
Date: Sun, 5 Aug 2018 18:46:49 +0100
Message-ID: <20180805174649.GI15082@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netdev@vger.kernel.org
To: Santosh Raspatur <santosh@chelsio.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:47446 "EHLO
        ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726362AbeHETwK (ORCPT
        <rfc822;netdev@vger.kernel.org>); Sun, 5 Aug 2018 15:52:10 -0400
Content-Disposition: inline
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

        for (i = 0; i < 2048; i++) {
...
                req->l2t_idx = htonl(V_L2T_W_IDX(i));
...
	
in there is very odd; l2t_idx is a 16bit field, and
#define V_L2T_W_IDX(x) ((x) << S_L2T_W_IDX)
#define S_L2T_W_IDX    0

IOW, we are taking htonl(something in range 0..2047) and
shove it into 16bit field.  Which would, on a little-endian
host, be a fancy way of spelling 
                req->l2t_idx = 0;

What's the intended behaviour there?  I'm not familiar with
the hardware in question; this smells like a typoed
	req->l2t_idx = htons(...)
but how does the current code manage to work (i.e. does
anything even care about the value stored there)?  It's not
a big-endian-only driver, after all...