aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/packetengines/hamachi.c
diff options
context:
space:
mode:
authorJarod Wilson <jarod@redhat.com>2016-10-07 22:04:33 -0400
committerDavid S. Miller <davem@davemloft.net>2016-10-13 09:36:56 -0400
commit61e84623ace35ce48975e8f90bbbac7557c43d61 (patch)
treeee8fbe9b7ec279152c80f1ca48a8a53e3b4620e2 /drivers/net/ethernet/packetengines/hamachi.c
parentMerge branch 's390-net' (diff)
downloadlinux-dev-61e84623ace35ce48975e8f90bbbac7557c43d61.tar.xz
linux-dev-61e84623ace35ce48975e8f90bbbac7557c43d61.zip
net: centralize net_device min/max MTU checking
While looking into an MTU issue with sfc, I started noticing that almost every NIC driver with an ndo_change_mtu function implemented almost exactly the same range checks, and in many cases, that was the only practical thing their ndo_change_mtu function was doing. Quite a few drivers have either 68, 64, 60 or 46 as their minimum MTU value checked, and then various sizes from 1500 to 65535 for their maximum MTU value. We can remove a whole lot of redundant code here if we simple store min_mtu and max_mtu in net_device, and check against those in net/core/dev.c's dev_set_mtu(). In theory, there should be zero functional change with this patch, it just puts the infrastructure in place. Subsequent patches will attempt to start using said infrastructure, with theoretically zero change in functionality. CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/packetengines/hamachi.c')
0 files changed, 0 insertions, 0 deletions