All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Miller <davem@davemloft.net>
Cc: linuxppc-dev@ozlabs.org, Li Yang <leoli@freescale.com>,
	Andy Fleming <afleming@freescale.com>,
	netdev@vger.kernel.org
Subject: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
Date: Wed, 24 Jun 2009 22:27:34 +0400	[thread overview]
Message-ID: <20090624182734.GA14306@oksana.dev.rtsoft.ru> (raw)

It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.

NFS boot using 10/half link takes about 10 minutes to complete:

  eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
  eth0: Running with NAPI enabled
  eth0: 256/256 RX/TX BD ring size
  [...]
  Sending DHCP requests .
  PHY: mdio@e0024520:02 - Link is Up - 10/Half
  ., OK
  [...]
  Looking up port of RPC 100003/2 on 10.0.0.2
  Looking up port of RPC 100005/1 on 10.0.0.2
  VFS: Mounted root (nfs filesystem) readonly on device 0:11.
  Freeing unused kernel memory: 188k init
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 OK
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 not responding, still trying
  [... few minutes of OK/not responding flood ...]

And just as with ucc_geth, statistic shows errors:

  # ethtool -S eth0 | grep -v ": 0"
  NIC statistics:
       rx-dropped-by-kernel: 2
       tx-rx-64-frames: 49
       tx-rx-65-127-frames: 1270
       tx-rx-128-255-frames: 9992
       tx-rx-256-511-frames: 75
       tx-rx-512-1023-frames: 142
       tx-rx-1024-1518-frames: 8828
       rx-bytes: 13299414
       rx-packets: 13122
       rx-jabber-frames: 9
       tx-byte-counter: 1284847
       tx-packets: 8115
       tx-broadcast-packets: 3
       tx-deferral-packets: 43
       tx-single-collision-packets: 15
       tx-multiple-collision-packets: 301
       tx-late-collision-packets: 872
       tx-total-collision: 999
       tx-undersize-frames: 6

The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.

It's no wonder though, QE Ethernet and TSEC are pretty similar.

[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/net/gianfar.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
 	if (phydev->link) {
 		u32 tempval = gfar_read(&regs->maccfg2);
 		u32 ecntrl = gfar_read(&regs->ecntrl);
+		phy_interface_t phyi = phydev->interface;
 
 		/* Now we make sure that we can be in full duplex mode.
 		 * If not, we operate in half-duplex mode. */
 		if (phydev->duplex != priv->oldduplex) {
 			new_state = 1;
-			if (!(phydev->duplex))
-				tempval &= ~(MACCFG2_FULL_DUPLEX);
+			if (!phydev->duplex &&
+					(phyi == PHY_INTERFACE_MODE_MII ||
+					 phyi == PHY_INTERFACE_MODE_RMII))
+				tempval &= ~MACCFG2_FULL_DUPLEX;
 			else
 				tempval |= MACCFG2_FULL_DUPLEX;
 
-- 
1.6.3.1

WARNING: multiple messages have this Message-ID (diff)
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Miller <davem@davemloft.net>
Cc: Kumar Gala <galak@kernel.crashing.org>,
	Andy Fleming <afleming@freescale.com>,
	Li Yang <leoli@freescale.com>,
	linuxppc-dev@ozlabs.org, netdev@vger.kernel.org
Subject: [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces
Date: Wed, 24 Jun 2009 22:27:34 +0400	[thread overview]
Message-ID: <20090624182734.GA14306@oksana.dev.rtsoft.ru> (raw)

It appears that gianfar driver has the same problem[1] that I
just fixed for ucc_geth.

NFS boot using 10/half link takes about 10 minutes to complete:

  eth0: Gianfar Ethernet Controller Version 1.2, 00:11:22:33:44:55
  eth0: Running with NAPI enabled
  eth0: 256/256 RX/TX BD ring size
  [...]
  Sending DHCP requests .
  PHY: mdio@e0024520:02 - Link is Up - 10/Half
  ., OK
  [...]
  Looking up port of RPC 100003/2 on 10.0.0.2
  Looking up port of RPC 100005/1 on 10.0.0.2
  VFS: Mounted root (nfs filesystem) readonly on device 0:11.
  Freeing unused kernel memory: 188k init
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 OK
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 not responding, still trying
  nfs: server 10.0.0.2 not responding, still trying
  [... few minutes of OK/not responding flood ...]

And just as with ucc_geth, statistic shows errors:

  # ethtool -S eth0 | grep -v ": 0"
  NIC statistics:
       rx-dropped-by-kernel: 2
       tx-rx-64-frames: 49
       tx-rx-65-127-frames: 1270
       tx-rx-128-255-frames: 9992
       tx-rx-256-511-frames: 75
       tx-rx-512-1023-frames: 142
       tx-rx-1024-1518-frames: 8828
       rx-bytes: 13299414
       rx-packets: 13122
       rx-jabber-frames: 9
       tx-byte-counter: 1284847
       tx-packets: 8115
       tx-broadcast-packets: 3
       tx-deferral-packets: 43
       tx-single-collision-packets: 15
       tx-multiple-collision-packets: 301
       tx-late-collision-packets: 872
       tx-total-collision: 999
       tx-undersize-frames: 6

The symptoms were observed on MPC8379E-RDB boards (eTSEC). Although
I didn't find where documentation forbids clearing Full Duplex bit
for non-MII/RMII modes, it's pretty distinct that the bit should be
set.

It's no wonder though, QE Ethernet and TSEC are pretty similar.

[1] http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073631.html

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/net/gianfar.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8741bb0..15dbffa 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -1984,13 +1984,16 @@ static void adjust_link(struct net_device *dev)
 	if (phydev->link) {
 		u32 tempval = gfar_read(&regs->maccfg2);
 		u32 ecntrl = gfar_read(&regs->ecntrl);
+		phy_interface_t phyi = phydev->interface;
 
 		/* Now we make sure that we can be in full duplex mode.
 		 * If not, we operate in half-duplex mode. */
 		if (phydev->duplex != priv->oldduplex) {
 			new_state = 1;
-			if (!(phydev->duplex))
-				tempval &= ~(MACCFG2_FULL_DUPLEX);
+			if (!phydev->duplex &&
+					(phyi == PHY_INTERFACE_MODE_MII ||
+					 phyi == PHY_INTERFACE_MODE_RMII))
+				tempval &= ~MACCFG2_FULL_DUPLEX;
 			else
 				tempval |= MACCFG2_FULL_DUPLEX;
 
-- 
1.6.3.1

             reply	other threads:[~2009-06-24 18:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-24 18:27 Anton Vorontsov [this message]
2009-06-24 18:27 ` [PATCH] gianfar: Fix half-duplex operation for non-MII/RMII interfaces Anton Vorontsov
2009-06-24 20:18 ` Andy Fleming
2009-06-24 21:10   ` Anton Vorontsov
2009-06-24 21:10     ` Anton Vorontsov
2009-06-24 21:25     ` Andy Fleming
2009-06-24 21:25       ` Andy Fleming
2009-06-24 21:39       ` Anton Vorontsov
2009-06-24 21:39         ` Anton Vorontsov
2009-06-24 21:50         ` Anton Vorontsov
2009-06-24 21:50           ` Anton Vorontsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090624182734.GA14306@oksana.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=afleming@freescale.com \
    --cc=davem@davemloft.net \
    --cc=leoli@freescale.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.