Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1394960 > unrolled thread

[PATCH 3/3] net-next: mediatek: add RX delay support

Started byJohn Crispin <john@phrozen.org>
First post2016-05-05 11:30 +0200
Last post2016-05-05 19:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 3/3] net-next: mediatek: add RX delay support John Crispin <john@phrozen.org> - 2016-05-05 11:30 +0200
    Re: [PATCH 3/3] net-next: mediatek: add RX delay support Andrew Lunn <andrew@lunn.ch> - 2016-05-05 14:20 +0200
      Re: [PATCH 3/3] net-next: mediatek: add RX delay support John Crispin <john@phrozen.org> - 2016-05-05 19:40 +0200

#1394960 — [PATCH 3/3] net-next: mediatek: add RX delay support

FromJohn Crispin <john@phrozen.org>
Date2016-05-05 11:30 +0200
Subject[PATCH 3/3] net-next: mediatek: add RX delay support
Message-ID<rvnLB-5Kz-37@gated-at.bofh.it>
If an external Gigabit PHY is connected to either of the MACs we need to
tell the to use a RX delay. Not doing so will result in heavy packet loss
and/or data corruption of RX traffic.

Signed-off-by: John Crispin <john@phrozen.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d397bec..41cdc0d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -226,6 +226,7 @@ static int mtk_phy_connect(struct mtk_mac *mac)
 		return -ENODEV;
 
 	switch (of_get_phy_mode(np)) {
+	case PHY_INTERFACE_MODE_RGMII_RXID:
 	case PHY_INTERFACE_MODE_RGMII:
 		ge_mode = 0;
 		break;
-- 
1.7.10.4

[toc] | [next] | [standalone]


#1395064

FromAndrew Lunn <andrew@lunn.ch>
Date2016-05-05 14:20 +0200
Message-ID<rvqq5-8en-3@gated-at.bofh.it>
In reply to#1394960
On Thu, May 05, 2016 at 11:17:36AM +0200, John Crispin wrote:
> If an external Gigabit PHY is connected to either of the MACs we need to
> tell the to use a RX delay. Not doing so will result in heavy packet loss
> and/or data corruption of RX traffic.

Hi John

Is this comment correct? Reading the code, all this switch statement
does is select between RGMII, MII and RMII. It has nothing to do with
delay. I suspect the PHY is doing the delay, not the MAC, since you
pass the phy mode to of_phy_connect().

If my interpretation of the code is correct, you might also want to
handle PHY_INTERFACE_MODE_RGMII_TXID and PHY_INTERFACE_MODE_RGMII_ID
which are also RGMII modes.

      Andrew

[toc] | [prev] | [next] | [standalone]


#1395251

FromJohn Crispin <john@phrozen.org>
Date2016-05-05 19:40 +0200
Message-ID<rvvpM-48v-17@gated-at.bofh.it>
In reply to#1395064

On 05/05/2016 14:13, Andrew Lunn wrote:
> On Thu, May 05, 2016 at 11:17:36AM +0200, John Crispin wrote:
>> If an external Gigabit PHY is connected to either of the MACs we need to
>> tell the to use a RX delay. Not doing so will result in heavy packet loss
>> and/or data corruption of RX traffic.
> 
> Hi John
> 
> Is this comment correct? Reading the code, all this switch statement
> does is select between RGMII, MII and RMII. It has nothing to do with
> delay. I suspect the PHY is doing the delay, not the MAC, since you
> pass the phy mode to of_phy_connect().
> 
> If my interpretation of the code is correct, you might also want to
> handle PHY_INTERFACE_MODE_RGMII_TXID and PHY_INTERFACE_MODE_RGMII_ID
> which are also RGMII modes.
> 
>       Andrew

Hi Andrew,

the comment is indeed incorrect and the PHY needs to handle the delay. i
will send a V2 and also add _TXID and _ID

	John

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web