sh_eth: use RNC mode for packet reception
authorBen Dooks <ben.dooks@codethink.co.uk>
Tue, 3 Jun 2014 11:21:13 +0000 (12:21 +0100)
committerJiri Slaby <jslaby@suse.cz>
Mon, 23 Jun 2014 08:28:01 +0000 (10:28 +0200)
commit84a6e2bdff418af6bd12d1086ec51ff6d0bb1ba6
tree237efb8af1bac2e8d3b643598f8e91a73b4171f8
parentdc4d3702659539dc9bdebf3bb4cfd4187c1cc9c5
sh_eth: use RNC mode for packet reception

[ Upstream commit 530aa2d0d9d55ab2775d47621ddf4b5b15bc1110 ]

The current behaviour of the sh_eth driver is not to use the RNC bit
for the receive ring. This means that every packet recieved is not only
generating an IRQ but it also stops the receive ring DMA as well until
the driver re-enables it after unloading the packet.

This means that a number of the following errors are generated due to
the receive packet FIFO overflowing due to nowhere to put packets:

net eth0: Receive FIFO Overflow

Since feedback from Yoshihiro Shimoda shows that every supported LSI
for this driver should have the bit enabled it seems the best way is
to remove the RMCR default value from the per-system data and just
write it when initialising the RMCR value. This is discussed in
the message (http://www.spinics.net/lists/netdev/msg284912.html).

I have tested the 0x00000001 configuration with NFS root filesystem and
the driver has not failed yet.  There are further test reports from
Sergei Shtylov and others for both the R8A7790 and R8A7791.

There is also feedback fron Cao Minh Hiep[1] which reports the
same issue in (http://comments.gmane.org/gmane.linux.network/316285)
showing this fixes issues with losing UDP datagrams under iperf.

Tested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
drivers/net/ethernet/renesas/sh_eth.c
drivers/net/ethernet/renesas/sh_eth.h