aboutsummaryrefslogtreecommitdiff
path: root/virt
diff options
context:
space:
mode:
authorLennert Buytenhek <buytenh@wantstofly.org>2008-07-11 00:39:41 +0200
committerLennert Buytenhek <buytenh@marvell.com>2008-07-24 06:22:51 +0200
commit65193a91fc60fdb79e392c9842c10552a1fa3e1c (patch)
tree767d12ee1ba8830232fed5ef7b56b85d20b18645 /virt
parent4dfc1c87af46f9d8abf2ef78a4e22891d7a564c3 (diff)
mv643xx_eth: don't fiddle with maximum receive packet size setting
The maximum receive packet size field in the Port Serial Control register controls at what size received packets are flagged overlength in the receive descriptor, but it doesn't prevent overlength packets from being DMAd to memory and signaled to the host like other received packets. mv643xx_eth does not support receiving jumbo frames in 10/100 mode, but setting the packet threshold to larger than 1522 bytes in 10/100 mode won't cause breakage by itself. If we really want to enforce maximum packet size on the receiving end instead of on the sending end where it should be done, we can always just add a length check to the software receive handler instead of relying on the hardware to do the comparison for us. What's more, changing the maximum packet size field requires temporarily disabling the RX/TX paths. So once the link comes up in 10/100 Mb/s mode or 1000 Mb/s mode, we'd have to disable it again just to set the right maximum packet size field (1522 in 10/100 Mb/s mode or 9700 in 1000 Mb/s mode), just so that we can offload one comparison operation to hardware that we might as well do in software, assuming that we'd want to do it at all. Contrary to what the documentation suggests, there is no harm in just setting a 9700 byte maximum packet size in 10/100 mode, so use the maximum maximum packet size for all modes. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions