bonding: Always assign be16 value to vlan_proto
The type of the vlan_proto field is __be16.
And most users of the field use it as such.
In the case of setting or testing the field for the special VLAN_N_VID
value, host byte order is used. Which seems incorrect.
It also seems somewhat odd to store a VLAN ID value in a field that is
otherwise used to store Ether types.
Address this issue by defining BOND_VLAN_PROTO_NONE, a big endian value.
0xffff was chosen somewhat arbitrarily. What is important is that it
doesn't overlap with any valid VLAN Ether types.
I don't believe the problems described above are a bug because
VLAN_N_VID in both little-endian and big-endian byte order does not
conflict with any supported VLAN Ether types in big-endian byte order.
Reported by sparse as:
.../bond_main.c:2857:26: warning: restricted __be16 degrades to integer
.../bond_main.c:2863:20: warning: restricted __be16 degrades to integer
.../bond_main.c:2939:40: warning: incorrect type in assignment (different base types)
.../bond_main.c:2939:40: expected restricted __be16 [usertype] vlan_proto
.../bond_main.c:2939:40: got int
No functional changes intended.
Compile tested only.
Signed-off-by: Simon Horman <horms@kernel.org>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>