[PATCH 0/3] net-next: mediatek: improve phy support

[PATCH 0/3] net-next: mediatek: improve phy support

[John Crispin]

This series contains 3 patches. One adds support for fixed-phy, making
boards work where the internal gigabit switch is used. Additionally the
series fixes support for GBit PHYs that so far only worked at 100Mbit.

John Crispin (3):
  net-next: mediatek: fix gigabit and flow control advertisement
  net-next: mediatek: add fixed-phy support
  net-next: mediatek: add RX delay support

 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

-- 
1.7.10.4

[PATCH 1/3] net-next: mediatek: fix gigabit and flow control advertisement

[John Crispin]

The current code will not setup the PHYs advertisement features correctly.
Fix this and properly advertise Gigabit features and properly handle
asymmetric pause frames.

Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index c984462..093073c 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -133,6 +133,8 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
 static void mtk_phy_link_adjust(struct net_device *dev)
 {
 	struct mtk_mac *mac = netdev_priv(dev);
+	u16 lcl_adv, rmt_adv = 0;
+	u8 flowctrl;
 	u32 mcr = MAC_MCR_MAX_RX_1536 | MAC_MCR_IPG_CFG |
 		  MAC_MCR_FORCE_MODE | MAC_MCR_TX_EN |
 		  MAC_MCR_RX_EN | MAC_MCR_BACKOFF_EN |
@@ -154,7 +156,16 @@ static void mtk_phy_link_adjust(struct net_device *dev)
 		mcr |= MAC_MCR_FORCE_DPX;
 
 	if (mac->phy_dev->pause)
-		mcr |= MAC_MCR_FORCE_RX_FC | MAC_MCR_FORCE_TX_FC;
+		rmt_adv = LPA_PAUSE_CAP;
+	if (mac->phy_dev->asym_pause)
+		rmt_adv |= LPA_PAUSE_ASYM;
+
+	lcl_adv = mii_advertise_flowctrl(FLOW_CTRL_RX | FLOW_CTRL_TX);
+	flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
+	if (flowctrl & FLOW_CTRL_TX)
+		mcr |= MAC_MCR_FORCE_TX_FC;
+	if (flowctrl & FLOW_CTRL_RX)
+		mcr |= MAC_MCR_FORCE_RX_FC;
 
 	mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
 
@@ -236,7 +247,8 @@ static int mtk_phy_connect(struct mtk_mac *mac)
 	mac->phy_dev->autoneg = AUTONEG_ENABLE;
 	mac->phy_dev->speed = 0;
 	mac->phy_dev->duplex = 0;
-	mac->phy_dev->supported &= PHY_BASIC_FEATURES;
+	mac->phy_dev->supported &= PHY_GBIT_FEATURES | SUPPORTED_Pause |
+				   ~SUPPORTED_Asym_Pause;
 	mac->phy_dev->advertising = mac->phy_dev->supported |
 				    ADVERTISED_Autoneg;
 	phy_start_aneg(mac->phy_dev);
-- 
1.7.10.4

[PATCH 2/3] net-next: mediatek: add fixed-phy support

[John Crispin]

The MT7623 SoC has a builtin gigabit switch. If we want to use it, GMAC1
needs to be configured using a fixed link speed and flow control settings.
The easiest way to do this is to used the fixed-phy driver, allowing us to
reuse the existing mdio polling code to setup the MAC.

Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 093073c..d397bec 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -219,6 +219,9 @@ static int mtk_phy_connect(struct mtk_mac *mac)
 	u32 val, ge_mode;
 
 	np = of_parse_phandle(mac->of_node, "phy-handle", 0);
+	if (!np && of_phy_is_fixed_link(mac->of_node))
+		if (!of_phy_register_fixed_link(mac->of_node))
+			np = of_node_get(mac->of_node);
 	if (!np)
 		return -ENODEV;
 
-- 
1.7.10.4

Re: [PATCH 2/3] net-next: mediatek: add fixed-phy support

[Andrew Lunn]

On Thu, May 05, 2016 at 11:17:35AM +0200, John Crispin wrote:
> The MT7623 SoC has a builtin gigabit switch. If we want to use it, GMAC1
> needs to be configured using a fixed link speed and flow control settings.
> The easiest way to do this is to used the fixed-phy driver, allowing us to
> reuse the existing mdio polling code to setup the MAC.
> 
> Signed-off-by: John Crispin <john@phrozen.org>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

Looks good.

      Andrew

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

[John Crispin]

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-Pj+rj9U5foFAfugRpC6u6w@public.gmane.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

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

[Andrew Lunn]

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

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

[John Crispin]

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

Re: [PATCH 0/3] net-next: mediatek: improve phy support

[David Miller]

Sorry, I'm not entertaining 3 seperate patch series for the same
driver at one time.  I'm removing all of these mediatek patches
from my queue.

Submit one series at a time please, thanks.