]> err.no Git - linux-2.6/commit
mv643xx_eth: don't fiddle with maximum receive packet size setting
authorLennert Buytenhek <buytenh@wantstofly.org>
Thu, 10 Jul 2008 22:39:41 +0000 (00:39 +0200)
committerLennert Buytenhek <buytenh@marvell.com>
Thu, 24 Jul 2008 04:22:51 +0000 (06:22 +0200)
commit65193a91fc60fdb79e392c9842c10552a1fa3e1c
tree767d12ee1ba8830232fed5ef7b56b85d20b18645
parent4dfc1c87af46f9d8abf2ef78a4e22891d7a564c3
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>
drivers/net/mv643xx_eth.c