diff options
author | Lennert Buytenhek <buytenh@wantstofly.org> | 2008-07-10 18:39:41 -0400 |
---|---|---|
committer | Lennert Buytenhek <buytenh@marvell.com> | 2008-07-24 00:22:51 -0400 |
commit | 65193a91fc60fdb79e392c9842c10552a1fa3e1c (patch) | |
tree | 767d12ee1ba8830232fed5ef7b56b85d20b18645 /drivers/net/sunqe.h | |
parent | 4dfc1c87af46f9d8abf2ef78a4e22891d7a564c3 (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 'drivers/net/sunqe.h')
0 files changed, 0 insertions, 0 deletions