[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k2jya8ot.fsf@ketchup.mtl.sfl>
Date: Fri, 15 Apr 2016 17:00:50 -0400
From: Vivien Didelot <vivien.didelot@...oirfairelinux.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel@...oirfairelinux.com,
"David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next 7/7] net: dsa: mv88e6xxx: drop switch id
Hi Andrew,
Andrew Lunn <andrew@...n.ch> writes:
<snip>
>> -#define PORT_SWITCH_ID_6350 0x3710
>> -#define PORT_SWITCH_ID_6351 0x3750
>> -#define PORT_SWITCH_ID_6352 0x3520
>
> NACK
>
> These numbers are not obvious. PORT_SWITCH_ID_6320 i can
> understand. 0x1150 i have no idea what it is.
0x1150 is not even correct. That's the product number (bits 4:15) masked
with an assumed revision 0 (bits 0:3).
That leads to confusion and error, as seen in the patch 2/7.
These values are now only used in a device description table, where they
seem pretty understandable to me.
This header file is full of inconsistencies. We have masks, offsets,
shifts, shifted and unshifted values, just for the sake of hidding said
magic numbers, while an explicit comment in a function could do the job.
But OK if we really want them defined, I'll introduce 12-bit
PORT_SWITCH_ID_PROD_NUM_* before dropping the 16-bit PORT_SWITCH_ID_*.
Thanks,
Vivien
Powered by blists - more mailing lists