[PATCH] net: macb: Properly handle phylink on at91sam9x

[Stefan Roese]

I just recently noticed that ethernet does not work anymore since v5.5
on the GARDENA smart Gateway, which is based on the AT91SAM9G25.
Debugging showed that the "GEM bits" in the NCFGR register are now
unconditionally accessed, which is incorrect for the !macb_is_gem()
case.

This patch adds the macb_is_gem() checks back to the code
(in macb_mac_config() & macb_mac_link_up()), so that the GEM register
bits are not accessed in this case any more.

Fixes: 7897b071ac3b ("net: macb: convert to phylink")
Signed-off-by: Stefan Roese 
Cc: Reto Schneider 
Cc: Alexandre Belloni 
Cc: Nicolas Ferre 
Cc: David S. Miller 
---
 drivers/net/ethernet/cadence/macb_main.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb_main.c 
b/drivers/net/ethernet/cadence/macb_main.c
index 2213e6ab8151..4b1b5928b104 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -578,7 +578,7 @@ static void macb_mac_config(struct phylink_config *config, 
unsigned int mode,
if (bp->caps & MACB_CAPS_MACB_IS_EMAC) {
if (state->interface == PHY_INTERFACE_MODE_RMII)
ctrl |= MACB_BIT(RM9200_RMII);
-   } else {
+   } else if (macb_is_gem(bp)) {
ctrl &= ~(GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL));
 
if (state->interface == PHY_INTERFACE_MODE_SGMII)
@@ -639,10 +639,13 @@ static void macb_mac_link_up(struct phylink_config 
*config,
ctrl |= MACB_BIT(FD);
 
if (!(bp->caps & MACB_CAPS_MACB_IS_EMAC)) {
-   ctrl &= ~(GEM_BIT(GBE) | MACB_BIT(PAE));
+   ctrl &= ~MACB_BIT(PAE);
+   if (macb_is_gem(bp)) {
+   ctrl &= ~GEM_BIT(GBE);
 
-   if (speed == SPEED_1000)
-   ctrl |= GEM_BIT(GBE);
+   if (speed == SPEED_1000)
+   ctrl |= GEM_BIT(GBE);
+   }
 
/* We do not support MLO_PAUSE_RX yet */
if (tx_pause)
-- 
2.28.0

[PATCH net-next 3/4 v3] net: ethernet: mediatek: Rename NEXT_RX_DESP_IDX to NEXT_DESP_IDX

[Stefan Roese]

Rename the NEXT_RX_DESP_IDX macro to NEXT_DESP_IDX, so that it better
can be used for TX ops as well. This will be used in the upcoming
MT7628/88 support (same functionality for RX and TX in this macro).

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v3:
- No change

v2:
- New patch

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bee2cdca66e7..d9978174b96a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -903,7 +903,7 @@ static struct mtk_rx_ring *mtk_get_rx_ring(struct mtk_eth 
*eth)
 
for (i = 0; i < MTK_MAX_RX_RING_NUM; i++) {
ring = ð->rx_ring[i];
-   idx = NEXT_RX_DESP_IDX(ring->calc_idx, ring->dma_size);
+   idx = NEXT_DESP_IDX(ring->calc_idx, ring->dma_size);
if (ring->dma[idx].rxd2 & RX_DMA_DONE) {
ring->calc_idx_update = true;
return ring;
@@ -952,7 +952,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
if (unlikely(!ring))
goto rx_done;
 
-   idx = NEXT_RX_DESP_IDX(ring->calc_idx, ring->dma_size);
+   idx = NEXT_DESP_IDX(ring->calc_idx, ring->dma_size);
rxd = &ring->dma[idx];
data = ring->data[idx];
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 088e2bc621f7..556644f28eae 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,7 @@
 NETIF_F_SG | NETIF_F_TSO | \
 NETIF_F_TSO6 | \
 NETIF_F_IPV6_CSUM)
-#define NEXT_RX_DESP_IDX(X, Y) (((X) + 1) & ((Y) - 1))
+#define NEXT_DESP_IDX(X, Y)(((X) + 1) & ((Y) - 1))
 
 #define MTK_MAX_RX_RING_NUM4
 #define MTK_HW_LRO_DMA_SIZE8
-- 
2.22.1

[PATCH net-next 4/4 v3] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v3:
- Corrected pointer arthmetic - use proper (void *) cast (David)

v2:
- Rebased on net-next (David)
- Used "ralink,rt5350-eth" compatible (Daniel)
- Fixed capability bit usage (Rene)
- Extracted DT bindings description to separate patch
- Introduced MTK_QDMA capability, which is used on all
  currently supported SoCs. Only the newly introcuded MT7628
  uses PDMA and does not have this capability bit set
- Added tx_int_mask_reg/tx_int_status_reg variables to better
  abstract the QDMA vs PDMA usage
  
 drivers/net/ethernet/mediatek/Kconfig|   2 +-
 drivers/net/ethernet/mediatek/mtk_eth_path.c |   4 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c  | 480 ++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h  |  51 +-
 4 files changed, 425 insertions(+), 112 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig 
b/drivers/net/ethernet/mediatek/Kconfig
index 1f7fff81f24d..b76cf2e1c9dc 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config NET_VENDOR_MEDIATEK
bool "MediaTek ethernet driver"
-   depends on ARCH_MEDIATEK || SOC_MT7621
+   depends on ARCH_MEDIATEK || SOC_MT7621 || SOC_MT7620
---help---
  If you have a Mediatek SoC with ethernet, say Y.
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c 
b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7f05880cf9ef..28960e4c4e43 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -315,6 +315,10 @@ int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int 
phymode)
 {
int err;
 
+   /* No mux'ing for MT7628/88 */
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
+   return 0;
+
switch (phymode) {
case PHY_INTERFACE_MODE_TRGMII:
case PHY_INTERFACE_MODE_RGMII_TXID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d9978174b96a..8ddbb8dcf032 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -323,11 +323,14 @@ static int mtk_phy_connect(struct net_device *dev)
goto err_phy;
}
 
-   /* put the gmac into the right mode */
-   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
-   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
-   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
-   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   /* No MT7628/88 support for now */
+   if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
+   /* put the gmac into the right mode */
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
+   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   }
 
/* couple phydev to net_device */
if (mtk_phy_connect_node(eth, mac, np))
@@ -395,8 +398,8 @@ static inline void mtk_tx_irq_disable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val & ~mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val & ~mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -406,8 +409,8 @@ static inline void mtk_tx_irq_enable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val | mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val | mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -437,6 +440,7 @@ static int mtk_set_mac_address(struct net_device *dev, void 
*p)
 {
int ret = eth_mac_addr(dev, p);
struct mtk_mac *mac = netdev_priv(dev);
+   struct mtk_eth *eth = mac->hw;
const char *macaddr = dev->dev_addr;
 
if (ret)
@@ -446,11 +450,19 @@ static int mtk_set_mac_address(struct net_device *dev, 
void *p)
return -EBUSY;
 
spin_lock_bh(&mac->hw->page_lock);
-   mtk_w32(mac->hw, (macaddr[0] << 8) | macaddr[1],
-   MTK_GDMA_MAC_ADRH(mac->id));
-   mtk_w32(mac->hw, (macaddr[2] << 24) | (

[PATCH net-next 2/4 v3] net: ethernet: mediatek: Rename MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS

[Stefan Roese]

Currently all QDMA registers are named "MTK_QDMA_foo" in this driver
with one exception: MTK_QMTK_INT_STATUS. This patch renames
MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS so that all macros follow
this rule.

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v3:
- No change

v2:
- New patch

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ddbffeb5701b..bee2cdca66e7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1122,11 +1122,11 @@ static int mtk_napi_tx(struct napi_struct *napi, int 
budget)
int tx_done = 0;
 
mtk_handle_status_irq(eth);
-   mtk_w32(eth, MTK_TX_DONE_INT, MTK_QMTK_INT_STATUS);
+   mtk_w32(eth, MTK_TX_DONE_INT, MTK_QDMA_INT_STATUS);
tx_done = mtk_poll_tx(eth, budget);
 
if (unlikely(netif_msg_intr(eth))) {
-   status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status = mtk_r32(eth, MTK_QDMA_INT_STATUS);
mask = mtk_r32(eth, MTK_QDMA_INT_MASK);
dev_info(eth->dev,
 "done tx %d, intr 0x%08x/0x%x\n",
@@ -1136,7 +1136,7 @@ static int mtk_napi_tx(struct napi_struct *napi, int 
budget)
if (tx_done == budget)
return budget;
 
-   status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status = mtk_r32(eth, MTK_QDMA_INT_STATUS);
if (status & MTK_TX_DONE_INT)
return budget;
 
@@ -1747,7 +1747,7 @@ static irqreturn_t mtk_handle_irq(int irq, void *_eth)
mtk_handle_irq_rx(irq, _eth);
}
if (mtk_r32(eth, MTK_QDMA_INT_MASK) & MTK_TX_DONE_INT) {
-   if (mtk_r32(eth, MTK_QMTK_INT_STATUS) & MTK_TX_DONE_INT)
+   if (mtk_r32(eth, MTK_QDMA_INT_STATUS) & MTK_TX_DONE_INT)
mtk_handle_irq_tx(irq, _eth);
}
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index bab94f763e2c..088e2bc621f7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -212,7 +212,7 @@
 #define FC_THRES_MIN   0x
 
 /* QDMA Interrupt Status Register */
-#define MTK_QMTK_INT_STATUS0x1A18
+#define MTK_QDMA_INT_STATUS0x1A18
 #define MTK_RX_DONE_DLYBIT(30)
 #define MTK_RX_DONE_INT3   BIT(19)
 #define MTK_RX_DONE_INT2   BIT(18)
-- 
2.22.1

[PATCH net-next 1/4 v3] dt-bindings: net: mediatek: Add support for MediaTek MT7628/88 SoC

[Stefan Roese]

Add compatible for the ethernet IP core on MT7628/88 SoCs. Its
compatible with the older Ralink Rt5350F SoC. And OpenWrt already
uses this compatible string for the MT76x8.

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
---
v3:
- No change

v2:
- New patch - bindings description moved to separate patch

 Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 770ff98d4524..72d03e07cf7c 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -12,6 +12,7 @@ Required properties:
"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
"mediatek,mt7622-eth": for MT7622 SoC
"mediatek,mt7629-eth": for MT7629 SoC
+   "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the three frame engines interrupts in numeric
order. These are fe_int0, fe_int1 and fe_int2.
-- 
2.22.1

Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

Hi Rene,

On 14.08.19 15:08, René van Dorst wrote:

Quoting Stefan Roese :


Hi Rene,

On 14.08.19 11:26, René van Dorst wrote:





Great, Thanks for addressing this issue.

I hope we can collaborate to also support mt76x8 in my PHYLINK
patches [0][1].
I am close to posting V2 of the patches but I am currently waiting on some
fiber modules to test the changes better.


I do have a "hackish" DSA driver for the integrated switch (ESW) in my
tree. If time permits, I'll work on upstreaming this one as well. And
yes, hopefully we can collaborate on your PHYLINK work too.


It is not only the switch driver but also the Mediatek ethernet driver that is
converted to PHYLINK. So we have a conflict in each others work.


Yes, I am aware of this.
 

I don't no what the right way is to go but I was thinking about 2 options

1. Lets say your work goes in first. I rebase my patches on your changes.
 We collaborate to create an extra PHYLINK patch ontop of my work
for your SOC.
2. My patches goes in first and you adapt your patches to that.

What do you think?


It really depends on the timing, when the patches arrive in the kernel
(net-next). If yours makes it first, I'll rebase my patch on top of
your work. Otherwise you will need to rebase yours.
 

I have latest changes here [0].

Also my modules did arrive so I can test my changes.


Thanks,
Stefan

[PATCH net-next 4/4 v2] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v2:
- Rebased on net-next (David)
- Used "ralink,rt5350-eth" compatible (Daniel)
- Fixed capability bit usage (Rene)
- Extracted DT bindings description to separate patch
- Introduced MTK_QDMA capability, which is used on all
  currently supported SoCs. Only the newly introcuded MT7628
  uses PDMA and does not have this capability bit set
- Added tx_int_mask_reg/tx_int_status_reg variables to better
  abstract the QDMA vs PDMA usage

 drivers/net/ethernet/mediatek/Kconfig|   2 +-
 drivers/net/ethernet/mediatek/mtk_eth_path.c |   4 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c  | 480 ++-
 drivers/net/ethernet/mediatek/mtk_eth_soc.h  |  51 +-
 4 files changed, 425 insertions(+), 112 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/Kconfig 
b/drivers/net/ethernet/mediatek/Kconfig
index 1f7fff81f24d..b76cf2e1c9dc 100644
--- a/drivers/net/ethernet/mediatek/Kconfig
+++ b/drivers/net/ethernet/mediatek/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config NET_VENDOR_MEDIATEK
bool "MediaTek ethernet driver"
-   depends on ARCH_MEDIATEK || SOC_MT7621
+   depends on ARCH_MEDIATEK || SOC_MT7621 || SOC_MT7620
---help---
  If you have a Mediatek SoC with ethernet, say Y.
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c 
b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7f05880cf9ef..28960e4c4e43 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -315,6 +315,10 @@ int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int 
phymode)
 {
int err;
 
+   /* No mux'ing for MT7628/88 */
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
+   return 0;
+
switch (phymode) {
case PHY_INTERFACE_MODE_TRGMII:
case PHY_INTERFACE_MODE_RGMII_TXID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index d9978174b96a..65eaafe6e975 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -323,11 +323,14 @@ static int mtk_phy_connect(struct net_device *dev)
goto err_phy;
}
 
-   /* put the gmac into the right mode */
-   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
-   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
-   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
-   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   /* No MT7628/88 support for now */
+   if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
+   /* put the gmac into the right mode */
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
+   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   }
 
/* couple phydev to net_device */
if (mtk_phy_connect_node(eth, mac, np))
@@ -395,8 +398,8 @@ static inline void mtk_tx_irq_disable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val & ~mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val & ~mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -406,8 +409,8 @@ static inline void mtk_tx_irq_enable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val | mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val | mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -437,6 +440,7 @@ static int mtk_set_mac_address(struct net_device *dev, void 
*p)
 {
int ret = eth_mac_addr(dev, p);
struct mtk_mac *mac = netdev_priv(dev);
+   struct mtk_eth *eth = mac->hw;
const char *macaddr = dev->dev_addr;
 
if (ret)
@@ -446,11 +450,19 @@ static int mtk_set_mac_address(struct net_device *dev, 
void *p)
return -EBUSY;
 
spin_lock_bh(&mac->hw->page_lock);
-   mtk_w32(mac->hw, (macaddr[0] << 8) | macaddr[1],
-   MTK_GDMA_MAC_ADRH(mac->id));
-   mtk_w32(mac->hw, (macaddr[2] << 24) | (macaddr[3] << 16) |
-   (macaddr[4] << 8) | macaddr[5],
-  

[PATCH net-next 2/4 v2] net: ethernet: mediatek: Rename MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS

[Stefan Roese]

Currently all QDMA registers are named "MTK_QDMA_foo" in this driver
with one exception: MTK_QMTK_INT_STATUS. This patch renames
MTK_QMTK_INT_STATUS to MTK_QDMA_INT_STATUS so that all macros follow
this rule.

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v2:
- New patch

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 8 
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ddbffeb5701b..bee2cdca66e7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1122,11 +1122,11 @@ static int mtk_napi_tx(struct napi_struct *napi, int 
budget)
int tx_done = 0;
 
mtk_handle_status_irq(eth);
-   mtk_w32(eth, MTK_TX_DONE_INT, MTK_QMTK_INT_STATUS);
+   mtk_w32(eth, MTK_TX_DONE_INT, MTK_QDMA_INT_STATUS);
tx_done = mtk_poll_tx(eth, budget);
 
if (unlikely(netif_msg_intr(eth))) {
-   status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status = mtk_r32(eth, MTK_QDMA_INT_STATUS);
mask = mtk_r32(eth, MTK_QDMA_INT_MASK);
dev_info(eth->dev,
 "done tx %d, intr 0x%08x/0x%x\n",
@@ -1136,7 +1136,7 @@ static int mtk_napi_tx(struct napi_struct *napi, int 
budget)
if (tx_done == budget)
return budget;
 
-   status = mtk_r32(eth, MTK_QMTK_INT_STATUS);
+   status = mtk_r32(eth, MTK_QDMA_INT_STATUS);
if (status & MTK_TX_DONE_INT)
return budget;
 
@@ -1747,7 +1747,7 @@ static irqreturn_t mtk_handle_irq(int irq, void *_eth)
mtk_handle_irq_rx(irq, _eth);
}
if (mtk_r32(eth, MTK_QDMA_INT_MASK) & MTK_TX_DONE_INT) {
-   if (mtk_r32(eth, MTK_QMTK_INT_STATUS) & MTK_TX_DONE_INT)
+   if (mtk_r32(eth, MTK_QDMA_INT_STATUS) & MTK_TX_DONE_INT)
mtk_handle_irq_tx(irq, _eth);
}
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index bab94f763e2c..088e2bc621f7 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -212,7 +212,7 @@
 #define FC_THRES_MIN   0x
 
 /* QDMA Interrupt Status Register */
-#define MTK_QMTK_INT_STATUS0x1A18
+#define MTK_QDMA_INT_STATUS0x1A18
 #define MTK_RX_DONE_DLYBIT(30)
 #define MTK_RX_DONE_INT3   BIT(19)
 #define MTK_RX_DONE_INT2   BIT(18)
-- 
2.22.1

[PATCH net-next 3/4 v2] net: ethernet: mediatek: Rename NEXT_RX_DESP_IDX to NEXT_DESP_IDX

[Stefan Roese]

Rename the NEXT_RX_DESP_IDX macro to NEXT_DESP_IDX, so that it better
can be used for TX ops as well. This will be used in the upcoming
MT7628/88 support (same functionality for RX and TX in this macro).

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
---
v2:
- New patch

 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++--
 drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index bee2cdca66e7..d9978174b96a 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -903,7 +903,7 @@ static struct mtk_rx_ring *mtk_get_rx_ring(struct mtk_eth 
*eth)
 
for (i = 0; i < MTK_MAX_RX_RING_NUM; i++) {
ring = ð->rx_ring[i];
-   idx = NEXT_RX_DESP_IDX(ring->calc_idx, ring->dma_size);
+   idx = NEXT_DESP_IDX(ring->calc_idx, ring->dma_size);
if (ring->dma[idx].rxd2 & RX_DMA_DONE) {
ring->calc_idx_update = true;
return ring;
@@ -952,7 +952,7 @@ static int mtk_poll_rx(struct napi_struct *napi, int budget,
if (unlikely(!ring))
goto rx_done;
 
-   idx = NEXT_RX_DESP_IDX(ring->calc_idx, ring->dma_size);
+   idx = NEXT_DESP_IDX(ring->calc_idx, ring->dma_size);
rxd = &ring->dma[idx];
data = ring->data[idx];
 
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 088e2bc621f7..556644f28eae 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,7 @@
 NETIF_F_SG | NETIF_F_TSO | \
 NETIF_F_TSO6 | \
 NETIF_F_IPV6_CSUM)
-#define NEXT_RX_DESP_IDX(X, Y) (((X) + 1) & ((Y) - 1))
+#define NEXT_DESP_IDX(X, Y)(((X) + 1) & ((Y) - 1))
 
 #define MTK_MAX_RX_RING_NUM4
 #define MTK_HW_LRO_DMA_SIZE8
-- 
2.22.1

[PATCH net-next 1/4 v2] dt-bindings: net: mediatek: Add support for MediaTek MT7628/88 SoC

[Stefan Roese]

Add compatible for the ethernet IP core on MT7628/88 SoCs. Its
compatible with the older Ralink Rt5350F SoC. And OpenWrt already
uses this compatible string for the MT76x8.

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Daniel Golle 
Cc: Sean Wang 
Cc: John Crispin 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
---
v2:
- New patch - bindings description moved to separate patch

Documentation/devicetree/bindings/net/mediatek-net.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 770ff98d4524..72d03e07cf7c 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -12,6 +12,7 @@ Required properties:
"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
"mediatek,mt7622-eth": for MT7622 SoC
"mediatek,mt7629-eth": for MT7629 SoC
+   "ralink,rt5350-eth": for Ralink Rt5350F and MT7628/88 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the three frame engines interrupts in numeric
order. These are fe_int0, fe_int1 and fe_int2.
-- 
2.22.1

Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

Hi Rene,

On 14.08.19 11:26, René van Dorst wrote:

Hi Stefan,

Quoting Stefan Roese :


Hi Rene,

On 17.07.19 14:53, René van Dorst wrote:




+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,8 @@
 NETIF_F_SG | NETIF_F_TSO | \
 NETIF_F_TSO6 | \
 NETIF_F_IPV6_CSUM)
-#define NEXT_RX_DESP_IDX(X, Y) (((X) + 1) & ((Y) - 1))
+#define MTK_HW_FEATURES_MT7628 (NETIF_F_SG | NETIF_F_RXCSUM)
+#define NEXT_DESP_IDX(X, Y)(((X) + 1) & ((Y) - 1))

  #define MTK_MAX_RX_RING_NUM   4
  #define MTK_HW_LRO_DMA_SIZE   8
@@ -118,6 +119,7 @@
  /* PDMA Global Configuration Register */
  #define MTK_PDMA_GLO_CFG  0xa04
  #define MTK_MULTI_EN  BIT(10)
+#define MTK_PDMA_SIZE_8DWORDS  (1 << 4)

  /* PDMA Reset Index Register */
  #define MTK_PDMA_RST_IDX  0xa08
@@ -276,11 +278,18 @@
  #define TX_DMA_OWNER_CPU  BIT(31)
  #define TX_DMA_LS0BIT(30)
  #define TX_DMA_PLEN0(_x)  (((_x) & MTK_TX_DMA_BUF_LEN) << 16)
+#define TX_DMA_PLEN1(_x)   ((_x) & MTK_TX_DMA_BUF_LEN)
  #define TX_DMA_SWCBIT(14)
  #define TX_DMA_SDL(_x)(((_x) & 0x3fff) << 16)

+/* PDMA on MT7628 */
+#define TX_DMA_DONEBIT(31)
+#define TX_DMA_LS1 BIT(14)
+#define TX_DMA_DESP2_DEF   (TX_DMA_LS0 | TX_DMA_DONE)
+
  /* QDMA descriptor rxd2 */
  #define RX_DMA_DONE   BIT(31)
+#define RX_DMA_LSO BIT(30)
  #define RX_DMA_PLEN0(_x)  (((_x) & 0x3fff) << 16)
  #define RX_DMA_GET_PLEN0(_x)  (((_x) >> 16) & 0x3fff)

@@ -289,6 +298,7 @@

  /* QDMA descriptor rxd4 */
  #define RX_DMA_L4_VALID   BIT(24)
+#define RX_DMA_L4_VALID_PDMA   BIT(30) /* when PDMA is used */
  #define RX_DMA_FPORT_SHIFT19
  #define RX_DMA_FPORT_MASK 0x7

@@ -412,6 +422,19 @@
  #define CO_QPHY_SELBIT(0)
  #define GEPHY_MAC_SEL  BIT(1)

+/* MT7628/88 specific stuff */
+#define MT7628_PDMA_OFFSET 0x0800
+#define MT7628_SDM_OFFSET  0x0c00
+
+#define MT7628_TX_BASE_PTR0(MT7628_PDMA_OFFSET + 0x00)
+#define MT7628_TX_MAX_CNT0 (MT7628_PDMA_OFFSET + 0x04)
+#define MT7628_TX_CTX_IDX0 (MT7628_PDMA_OFFSET + 0x08)
+#define MT7628_TX_DTX_IDX0 (MT7628_PDMA_OFFSET + 0x0c)
+#define MT7628_PST_DTX_IDX0BIT(0)
+
+#define MT7628_SDM_MAC_ADRL(MT7628_SDM_OFFSET + 0x0c)
+#define MT7628_SDM_MAC_ADRH(MT7628_SDM_OFFSET + 0x10)
+
  struct mtk_rx_dma {
unsigned int rxd1;
unsigned int rxd2;
@@ -509,6 +532,7 @@ enum mtk_clks_map {
 BIT(MTK_CLK_SGMII_CK) | \
 BIT(MTK_CLK_ETH2PLL))
  #define MT7621_CLKS_BITMAP(0)
+#define MT7628_CLKS_BITMAP (0)
  #define MT7629_CLKS_BITMAP(BIT(MTK_CLK_ETHIF) | BIT(MTK_CLK_ESW) |  \
 BIT(MTK_CLK_GP0) | BIT(MTK_CLK_GP1) | \
 BIT(MTK_CLK_GP2) | BIT(MTK_CLK_FE) | \
@@ -563,6 +587,10 @@ struct mtk_tx_ring {
struct mtk_tx_dma *last_free;
u16 thresh;
atomic_t free_count;
+   int dma_size;
+   struct mtk_tx_dma *dma_pdma;/* For MT7628/88 PDMA handling */
+   dma_addr_t phys_pdma;
+   int cpu_idx;
  };

  /* PDMA rx ring mode */
@@ -604,6 +632,7 @@ enum mkt_eth_capabilities {
MTK_HWLRO_BIT,
MTK_SHARED_INT_BIT,
MTK_TRGMII_MT7621_CLK_BIT,
+   MTK_SOC_MT7628,


This should be MTK_SOC_MT7628_BIT, this only defines the bit number!

and futher on #define MTK_SOC_MT7628 BIT(MTK_SOC_MT7628_BIT)


Okay, thanks.


Based on this commit [0], MT7621 also needs the PDMA for the RX path.
I know that is not your issue but I think it is better to add a extra
capability bit for the PDMA bits so it can also be used on other socs.


Yes, MT7621 also uses PDMA for RX. The code for RX is pretty much
shared (re-used), with slight changes for the MT7628/88 to work
correctly on this SoC.

I'll work on a capability bit for PDMA vs QDMA on TX though. This
might make things a little more transparent.


Great, Thanks for addressing this issue.

I hope we can collaborate to also support mt76x8 in my PHYLINK patches [0][1].
I am close to posting V2 of the patches but I am currently waiting on some
fiber modules to test the changes better.


I do have a "hackish" DSA driver for the integrated switch (ESW) in my
tree. If time permits, I'll work on upstreaming this one as well. And
yes, hopefully we can collaborate on your PHYLINK work too.

Thanks,
Stefan

Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

Hi Rene,

On 17.07.19 14:53, René van Dorst wrote:




+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -39,7 +39,8 @@
 NETIF_F_SG | NETIF_F_TSO | \
 NETIF_F_TSO6 | \
 NETIF_F_IPV6_CSUM)
-#define NEXT_RX_DESP_IDX(X, Y) (((X) + 1) & ((Y) - 1))
+#define MTK_HW_FEATURES_MT7628 (NETIF_F_SG | NETIF_F_RXCSUM)
+#define NEXT_DESP_IDX(X, Y)(((X) + 1) & ((Y) - 1))

  #define MTK_MAX_RX_RING_NUM   4
  #define MTK_HW_LRO_DMA_SIZE   8
@@ -118,6 +119,7 @@
  /* PDMA Global Configuration Register */
  #define MTK_PDMA_GLO_CFG  0xa04
  #define MTK_MULTI_EN  BIT(10)
+#define MTK_PDMA_SIZE_8DWORDS  (1 << 4)

  /* PDMA Reset Index Register */
  #define MTK_PDMA_RST_IDX  0xa08
@@ -276,11 +278,18 @@
  #define TX_DMA_OWNER_CPU  BIT(31)
  #define TX_DMA_LS0BIT(30)
  #define TX_DMA_PLEN0(_x)  (((_x) & MTK_TX_DMA_BUF_LEN) << 16)
+#define TX_DMA_PLEN1(_x)   ((_x) & MTK_TX_DMA_BUF_LEN)
  #define TX_DMA_SWCBIT(14)
  #define TX_DMA_SDL(_x)(((_x) & 0x3fff) << 16)

+/* PDMA on MT7628 */
+#define TX_DMA_DONEBIT(31)
+#define TX_DMA_LS1 BIT(14)
+#define TX_DMA_DESP2_DEF   (TX_DMA_LS0 | TX_DMA_DONE)
+
  /* QDMA descriptor rxd2 */
  #define RX_DMA_DONE   BIT(31)
+#define RX_DMA_LSO BIT(30)
  #define RX_DMA_PLEN0(_x)  (((_x) & 0x3fff) << 16)
  #define RX_DMA_GET_PLEN0(_x)  (((_x) >> 16) & 0x3fff)

@@ -289,6 +298,7 @@

  /* QDMA descriptor rxd4 */
  #define RX_DMA_L4_VALID   BIT(24)
+#define RX_DMA_L4_VALID_PDMA   BIT(30) /* when PDMA is used */
  #define RX_DMA_FPORT_SHIFT19
  #define RX_DMA_FPORT_MASK 0x7

@@ -412,6 +422,19 @@
  #define CO_QPHY_SELBIT(0)
  #define GEPHY_MAC_SEL  BIT(1)

+/* MT7628/88 specific stuff */
+#define MT7628_PDMA_OFFSET 0x0800
+#define MT7628_SDM_OFFSET  0x0c00
+
+#define MT7628_TX_BASE_PTR0(MT7628_PDMA_OFFSET + 0x00)
+#define MT7628_TX_MAX_CNT0 (MT7628_PDMA_OFFSET + 0x04)
+#define MT7628_TX_CTX_IDX0 (MT7628_PDMA_OFFSET + 0x08)
+#define MT7628_TX_DTX_IDX0 (MT7628_PDMA_OFFSET + 0x0c)
+#define MT7628_PST_DTX_IDX0BIT(0)
+
+#define MT7628_SDM_MAC_ADRL(MT7628_SDM_OFFSET + 0x0c)
+#define MT7628_SDM_MAC_ADRH(MT7628_SDM_OFFSET + 0x10)
+
  struct mtk_rx_dma {
unsigned int rxd1;
unsigned int rxd2;
@@ -509,6 +532,7 @@ enum mtk_clks_map {
 BIT(MTK_CLK_SGMII_CK) | \
 BIT(MTK_CLK_ETH2PLL))
  #define MT7621_CLKS_BITMAP(0)
+#define MT7628_CLKS_BITMAP (0)
  #define MT7629_CLKS_BITMAP(BIT(MTK_CLK_ETHIF) | BIT(MTK_CLK_ESW) |  \
 BIT(MTK_CLK_GP0) | BIT(MTK_CLK_GP1) | \
 BIT(MTK_CLK_GP2) | BIT(MTK_CLK_FE) | \
@@ -563,6 +587,10 @@ struct mtk_tx_ring {
struct mtk_tx_dma *last_free;
u16 thresh;
atomic_t free_count;
+   int dma_size;
+   struct mtk_tx_dma *dma_pdma;/* For MT7628/88 PDMA handling */
+   dma_addr_t phys_pdma;
+   int cpu_idx;
  };

  /* PDMA rx ring mode */
@@ -604,6 +632,7 @@ enum mkt_eth_capabilities {
MTK_HWLRO_BIT,
MTK_SHARED_INT_BIT,
MTK_TRGMII_MT7621_CLK_BIT,
+   MTK_SOC_MT7628,


This should be MTK_SOC_MT7628_BIT, this only defines the bit number!

and futher on #define MTK_SOC_MT7628 BIT(MTK_SOC_MT7628_BIT)


Okay, thanks.
 

Based on this commit [0], MT7621 also needs the PDMA for the RX path.
I know that is not your issue but I think it is better to add a extra
capability bit for the PDMA bits so it can also be used on other socs.


Yes, MT7621 also uses PDMA for RX. The code for RX is pretty much
shared (re-used), with slight changes for the MT7628/88 to work
correctly on this SoC.

I'll work on a capability bit for PDMA vs QDMA on TX though. This
might make things a little more transparent.
 

Greats,

René

[0] https://lkml.org/lkml/2018/3/14/1038


Thanks,
Stefan

Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

On 17.07.19 14:15, Daniel Golle wrote:

On Wed, Jul 17, 2019 at 01:02:43PM +0200, Stefan Roese wrote:

This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).


The Ethernet core found in MT7628/88 is identical to that found in
Ralink Rt5350F SoC. Wouldn't it hence make sense to indicate that
in the compatible string of this driver as well? In OpenWrt we are
using "ralink,rt5350-eth".


Okay. I'll use this ralink compatible instead in the next version.

Thanks,
Stefan

Re: [PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

On 17.07.19 14:15, Daniel Golle wrote:

On Wed, Jul 17, 2019 at 01:02:43PM +0200, Stefan Roese wrote:

This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).


The Ethernet core found in MT7628/88 is identical to that found in
Ralink Rt5350F SoC. Wouldn't it hence make sense to indicate that
in the compatible string of this driver as well? In OpenWrt we are
using "ralink,rt5350-eth".


Yes sure, I can switch back to the original compatible string.

I'm on vacation for a bit over 2 weeks now and will try to address
all review comments after that.

Thanks,
Stefan
 




Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Sean Wang 
Cc: Felix Fietkau 
Cc: John Crispin 
---
  .../devicetree/bindings/net/mediatek-net.txt  |   1 +
  drivers/net/ethernet/mediatek/mtk_eth_path.c  |   4 +
  drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 490 ++
  drivers/net/ethernet/mediatek/mtk_eth_soc.h   |  39 +-
  4 files changed, 424 insertions(+), 110 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 770ff98d4524..ec6793562148 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -11,6 +11,7 @@ Required properties:
"mediatek,mt2701-eth": for MT2701 SoC
"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
"mediatek,mt7622-eth": for MT7622 SoC
+   "mediatek,mt7628-eth": for MT7628/88 SoC
"mediatek,mt7629-eth": for MT7629 SoC
  - reg: Address and length of the register set for the device
  - interrupts: Should contain the three frame engines interrupts in numeric
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c 
b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7f05880cf9ef..28960e4c4e43 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -315,6 +315,10 @@ int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int 
phymode)
  {
int err;
  
+	/* No mux'ing for MT7628/88 */

+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
+   return 0;
+
switch (phymode) {
case PHY_INTERFACE_MODE_TRGMII:
case PHY_INTERFACE_MODE_RGMII_TXID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b20b3a5a1ebb..1f248ef6ef88 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -323,11 +323,14 @@ static int mtk_phy_connect(struct net_device *dev)
goto err_phy;
}
  
-	/* put the gmac into the right mode */

-   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
-   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
-   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
-   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   /* No MT7628/88 support for now */
+   if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
+   /* put the gmac into the right mode */
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
+   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   }
  
  	/* couple phydev to net_device */

if (mtk_phy_connect_node(eth, mac, np))
@@ -395,8 +398,8 @@ static inline void mtk_tx_irq_disable(struct mtk_eth *eth, 
u32 mask)
u32 val;
  
  	spin_lock_irqsave(ð->tx_irq_lock, flags);

-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val & ~mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val & ~mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
  }
  
@@ -406,8 +409,8 @@ static inline void mtk_tx_irq_enable(struct mtk_eth *eth, u32 mask)

u32 val;
  
  	spin_lock_irqsave(ð->tx_irq_lock, flags);

-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val | mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val | mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
  }
  
@@ -437,6 +440,7 @@ static int mtk_set_mac_address(struct net_device *dev, void *p)

  {
int ret = eth_mac_addr(dev, p);
struct mtk_mac *mac = netdev_priv(dev);
+   struct mtk_eth *eth = mac->hw;
const char *macaddr = dev->dev_addr;
  
  	if (ret)

@@ -446,11 +450,19 @@ static int 

[PATCH] net: ethernet: mediatek: Add MT7628/88 SoC support

[Stefan Roese]

This patch adds support for the MediaTek MT7628/88 SoCs to the common
MediaTek ethernet driver. Some minor changes are needed for this and
a bigger change, as the MT7628 does not support QDMA (only PDMA).

Signed-off-by: Stefan Roese 
Cc: René van Dorst 
Cc: Sean Wang 
Cc: Felix Fietkau 
Cc: John Crispin 
---
 .../devicetree/bindings/net/mediatek-net.txt  |   1 +
 drivers/net/ethernet/mediatek/mtk_eth_path.c  |   4 +
 drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 490 ++
 drivers/net/ethernet/mediatek/mtk_eth_soc.h   |  39 +-
 4 files changed, 424 insertions(+), 110 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt 
b/Documentation/devicetree/bindings/net/mediatek-net.txt
index 770ff98d4524..ec6793562148 100644
--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
+++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
@@ -11,6 +11,7 @@ Required properties:
"mediatek,mt2701-eth": for MT2701 SoC
"mediatek,mt7623-eth", "mediatek,mt2701-eth": for MT7623 SoC
"mediatek,mt7622-eth": for MT7622 SoC
+   "mediatek,mt7628-eth": for MT7628/88 SoC
"mediatek,mt7629-eth": for MT7629 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the three frame engines interrupts in numeric
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c 
b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7f05880cf9ef..28960e4c4e43 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -315,6 +315,10 @@ int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int 
phymode)
 {
int err;
 
+   /* No mux'ing for MT7628/88 */
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628))
+   return 0;
+
switch (phymode) {
case PHY_INTERFACE_MODE_TRGMII:
case PHY_INTERFACE_MODE_RGMII_TXID:
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index b20b3a5a1ebb..1f248ef6ef88 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -323,11 +323,14 @@ static int mtk_phy_connect(struct net_device *dev)
goto err_phy;
}
 
-   /* put the gmac into the right mode */
-   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
-   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
-   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
-   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   /* No MT7628/88 support for now */
+   if (!MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
+   /* put the gmac into the right mode */
+   regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+   val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
+   val |= SYSCFG0_GE_MODE(mac->ge_mode, mac->id);
+   regmap_write(eth->ethsys, ETHSYS_SYSCFG0, val);
+   }
 
/* couple phydev to net_device */
if (mtk_phy_connect_node(eth, mac, np))
@@ -395,8 +398,8 @@ static inline void mtk_tx_irq_disable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val & ~mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val & ~mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -406,8 +409,8 @@ static inline void mtk_tx_irq_enable(struct mtk_eth *eth, 
u32 mask)
u32 val;
 
spin_lock_irqsave(ð->tx_irq_lock, flags);
-   val = mtk_r32(eth, MTK_QDMA_INT_MASK);
-   mtk_w32(eth, val | mask, MTK_QDMA_INT_MASK);
+   val = mtk_r32(eth, eth->tx_int_mask_reg);
+   mtk_w32(eth, val | mask, eth->tx_int_mask_reg);
spin_unlock_irqrestore(ð->tx_irq_lock, flags);
 }
 
@@ -437,6 +440,7 @@ static int mtk_set_mac_address(struct net_device *dev, void 
*p)
 {
int ret = eth_mac_addr(dev, p);
struct mtk_mac *mac = netdev_priv(dev);
+   struct mtk_eth *eth = mac->hw;
const char *macaddr = dev->dev_addr;
 
if (ret)
@@ -446,11 +450,19 @@ static int mtk_set_mac_address(struct net_device *dev, 
void *p)
return -EBUSY;
 
spin_lock_bh(&mac->hw->page_lock);
-   mtk_w32(mac->hw, (macaddr[0] << 8) | macaddr[1],
-   MTK_GDMA_MAC_ADRH(mac->id));
-   mtk_w32(mac->hw, (macaddr[2] << 24) | (macaddr[3] << 16) |
-   (macaddr[4] << 8) | macaddr[5],
-   MTK_GDMA_MAC_ADRL(mac->id));
+   if (MTK_HAS_CAPS(eth->soc->caps, MTK_SOC_MT7628)) {
+   mtk_w32(ma

[PATCH] net: phy: Add SGMII support for Marvell 88E1510/1512/1514/1518

[Stefan Roese]

Add code to select SGMII-to-copper mode upon SGMII interface selection.

Signed-off-by: Stefan Roese 
Cc: Andrew Lunn 
Cc: Florian Fainelli 
Cc: David S. Miller 
---
 drivers/net/phy/marvell.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index e3eb964..1dcbd3f 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -133,6 +133,11 @@
 #define MII_88E3016_DISABLE_SCRAMBLER  0x0200
 #define MII_88E3016_AUTO_MDIX_CROSSOVER0x0030
 
+#define MII_88E1510_GEN_CTRL_REG_1 0x14
+#define MII_88E1510_GEN_CTRL_REG_1_MODE_MASK   0x7
+#define MII_88E1510_GEN_CTRL_REG_1_MODE_SGMII  0x1 /* SGMII to copper */
+#define MII_88E1510_GEN_CTRL_REG_1_RESET   0x8000  /* Soft reset */
+
 MODULE_DESCRIPTION("Marvell PHY driver");
 MODULE_AUTHOR("Andy Fleming");
 MODULE_LICENSE("GPL");
@@ -438,6 +443,41 @@ static int m88e1318_config_aneg(struct phy_device *phydev)
return m88e1121_config_aneg(phydev);
 }
 
+static int m88e1510_config_init(struct phy_device *phydev)
+{
+   int err;
+   int temp;
+
+   /* SGMII-to-Copper mode initialization */
+   if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+   /* Select page 18 */
+   err = phy_write(phydev, MII_MARVELL_PHY_PAGE, 18);
+   if (err < 0)
+   return err;
+
+   /* In reg 20, write MODE[2:0] = 0x1 (SGMII to Copper) */
+   temp = phy_read(phydev, MII_88E1510_GEN_CTRL_REG_1);
+   temp &= ~MII_88E1510_GEN_CTRL_REG_1_MODE_MASK;
+   temp |= MII_88E1510_GEN_CTRL_REG_1_MODE_SGMII;
+   err = phy_write(phydev, MII_88E1510_GEN_CTRL_REG_1, temp);
+   if (err < 0)
+   return err;
+
+   /* PHY reset is necessary after changing MODE[2:0] */
+   temp |= MII_88E1510_GEN_CTRL_REG_1_RESET;
+   err = phy_write(phydev, MII_88E1510_GEN_CTRL_REG_1, temp);
+   if (err < 0)
+   return err;
+
+   /* Reset page selection */
+   err = phy_write(phydev, MII_MARVELL_PHY_PAGE, 0);
+   if (err < 0)
+   return err;
+   }
+
+   return 0;
+}
+
 static int m88e1510_config_aneg(struct phy_device *phydev)
 {
int err;
@@ -1259,6 +1299,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
+   .config_init = &m88e1510_config_init,
.config_aneg = &m88e1510_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
-- 
2.7.1

[PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table

[Stefan Roese]

With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/rgmii.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
 static struct of_device_id rgmii_match[] =
 {
{
-   .type   = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table

[Stefan Roese]

On Wednesday 06 February 2008, Jeff Garzik wrote:
> > Jeff, any chance this can get into .25 soon?  I have another patch
> > queued up behind this one that requires it, and I don't see it in any
> > of your trees or branches.
> >
> > Or, if you aren't opposed, I can take it through Paul's tree with your
> > Ack.
>
> can you resend?  I don't see it in the pile

Will do.

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table

[Stefan Roese]

On Wednesday 16 January 2008, Josh Boyer wrote:
> On Wed, 16 Jan 2008 20:53:59 +1100
>
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > With the removal the the "rgmii-interface" device_type property from
> > > the dts files, the newemac driver needs an update to only rely on
> > > compatible property.
> > >
> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> >
> > I need to test if it works on CAB, can't change the DT on those. I'll
> > let you know tomorrow.
>
> This should be fine on CAB.  The rgmii node has:
>
> compatible = "ibm,rgmii-axon", "ibm,rgmii"
>
> so the match should still catch on the latter.

How about this patch? Ben, if you think this is ok then we should make sure 
that it goes in in this merge-window, since the other dts patch relies on it.

Thanks.

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table

[Stefan Roese]

With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/rgmii.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
 static struct of_device_id rgmii_match[] =
 {
{
-   .type   = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's

[Stefan Roese]

Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.

This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/core.c |   14 --
 1 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280..b24bd2d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct 
net_device *ndev)
return emac_xmit_finish(dev, len);
 }
 
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
 static inline int emac_xmit_split(struct emac_instance *dev, int slot,
  u32 pd, int len, int last, u16 base_ctrl)
 {
@@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct 
net_device *ndev)
DBG2(dev, "stopped TX queue" NL);
return 1;
 }
-#else
-# define emac_start_xmit_sgemac_start_xmit
-#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
 
 /* Tx lock BHs */
 static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
@@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
 
/* Fill in the driver function table */
ndev->open = &emac_open;
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
-   if (dev->tah_dev) {
-   ndev->hard_start_xmit = &emac_start_xmit_sg;
+   if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
-   } else
-#endif
-   ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(dev->phy_mode)) {
+   ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+   } else {
+   ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
 
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's

[Stefan Roese]

Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.

This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.

Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_emac/ibm_emac_core.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ibm_emac/ibm_emac_core.c 
b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..8d1901e 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct 
net_device *ndev)
return emac_xmit_finish(dev, len);
 }
 
-#if defined(CONFIG_IBM_EMAC_TAH)
 static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
  u32 pd, int len, int last, u16 base_ctrl)
 {
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct 
net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
 }
-#else
-# define emac_start_xmit_sgemac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
 
 /* BHs disabled */
 static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,8 @@ static int __init emac_probe(struct ocp_device *ocpdev)
 
/* Fill in the driver function table */
ndev->open = &emac_open;
-   if (dev->tah_dev) {
-   ndev->hard_start_xmit = &emac_start_xmit_sg;
+   if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
-   } else
-   ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2175,8 +2168,11 @@ static int __init emac_probe(struct ocp_device *ocpdev)
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(emacdata->phy_mode)) {
+   ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+   } else {
+   ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
 
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's

[Stefan Roese]

On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
> change MTU you cannot get big frames.

Ahhh, I must have been blind. Thanks for pointing out.

I'll send new patches for ibm_emac and ibm_newemac in a short while.

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's

[Stefan Roese]

On Tuesday 15 January 2008, Eugene Surovegin wrote:
> On Tue, Jan 15, 2008 at 01:40:09PM +0100, Stefan Roese wrote:
> > Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> > xmit. This routine doesn't check if the frame length exceeds the max.
> > MAL buffer size.
> >
> > This patch now changes the driver to call emac_start_xmit_sg() on all
> > platforms and not only the TAH equipped ones (440GX). This enables an
> > MTU of 9000 instead 4080.
> >
> > Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.
> >
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > ---
> > Eugene & Ben, do you see any problems with this patch? If not, then I'll
> > send another version for the newemac driver too.
>
> Hmm, so why not make GigE support a condition to hook SG version of
> xmit then? I don't like when you change behaviour for chips where it
> perefectly legal not to do this check because you cannot change MTU
> anyways.

OK. But how do we detect GigE support? Seems like GigE enabled devices have 
CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another version 
tomorrow.

Thanks.

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's

[Stefan Roese]

Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.

This patch now changes the driver to call emac_start_xmit_sg() on all
platforms and not only the TAH equipped ones (440GX). This enables an
MTU of 9000 instead 4080.

Tested on Kilauea (405EX) with gbit link -> jumbo frames enabled.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
Eugene & Ben, do you see any problems with this patch? If not, then I'll
send another version for the newemac driver too.

Thanks.

 drivers/net/ibm_emac/ibm_emac_core.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ibm_emac/ibm_emac_core.c 
b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..198de44 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct 
net_device *ndev)
return emac_xmit_finish(dev, len);
 }
 
-#if defined(CONFIG_IBM_EMAC_TAH)
 static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
  u32 pd, int len, int last, u16 base_ctrl)
 {
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct 
net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
 }
-#else
-# define emac_start_xmit_sgemac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
 
 /* BHs disabled */
 static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,9 @@ static int __init emac_probe(struct ocp_device *ocpdev)
 
/* Fill in the driver function table */
ndev->open = &emac_open;
-   if (dev->tah_dev) {
-   ndev->hard_start_xmit = &emac_start_xmit_sg;
+   ndev->hard_start_xmit = &emac_start_xmit_sg;
+   if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
-   } else
-   ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
-- 
1.5.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers

[Stefan Roese]

On Friday 11 January 2008, Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote:
> > On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> > > On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > > > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > > > Performance tests done by AMCC have shown that 256 buffer increase
> > > > > the performance of the Linux EMAC driver. So let's update the
> > > > > default values to match this setup.
> > > > >
> > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > > > > ---
> > > >
> > > > Do we have the numbers ? Did they also measure latency ?
> > >
> > > I hoped this question would not come. ;) No, unfortunately I don't have
> > > any numbers. Just the recommendation from AMCC to always use 256
> > > buffers.
> >
> > This cannot be true for all chips. Default numbers I selected weren't
> > random. In particular, 256 for Tx doesn't make a lot of sense for 405.
> > You just gonna waste memory.

This may be the case with the "old" 405 PPC's. But with the new ones coming 
out right now, like the up to 666MHz 405EX with GBit support, 256 could be an 
improvement. I still owe you figures though. Will try to do some testing in a 
short while.

> > I'd be quite reluctant to follow such advices from AMCC without actual
> > details.
>
> I think we can make defaults based on other config options nowadays. Not
> very nice but we could do things like
>
>   default 128 if PPC_40x
>   default 256
>
> Or even more detailed.

We shouldn't make it too complicated. We can always select different settings 
in the defconfig file. My thinking here is to better wast a little memory 
with a potential performance improvement. Just me 0.02$

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers

[Stefan Roese]

On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > Performance tests done by AMCC have shown that 256 buffer increase the
> > performance of the Linux EMAC driver. So let's update the default
> > values to match this setup.
> >
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> > ---
>
> Do we have the numbers ? Did they also measure latency ?

I hoped this question would not come. ;) No, unfortunately I don't have any 
numbers. Just the recommendation from AMCC to always use 256 buffers.

Best regards,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ibm_newemac: Increase number of default rx-/tx-buffers

[Stefan Roese]

Performance tests done by AMCC have shown that 256 buffer increase the
performance of the Linux EMAC driver. So let's update the default
values to match this setup.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ibm_newemac/Kconfig b/drivers/net/ibm_newemac/Kconfig
index 0d3e738..5a06727 100644
--- a/drivers/net/ibm_newemac/Kconfig
+++ b/drivers/net/ibm_newemac/Kconfig
@@ -9,12 +9,12 @@ config IBM_NEW_EMAC
 config IBM_NEW_EMAC_RXB
int "Number of receive buffers"
depends on IBM_NEW_EMAC
-   default "128"
+   default "256"
 
 config IBM_NEW_EMAC_TXB
int "Number of transmit buffers"
depends on IBM_NEW_EMAC
-   default "64"
+   default "256"
 
 config IBM_NEW_EMAC_POLL_WEIGHT
int "MAL NAPI polling weight"
-- 
1.5.4.rc2

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 8/8] ibm_newemac: Skip EMACs that are marked unused by the firmware

[Stefan Roese]

On Wednesday 21 November 2007, Benjamin Herrenschmidt wrote:
> From: Hugh Blemings <[EMAIL PROTECTED]>
>
> Depending on how the 44x processors are wired, some EMAC cells
> might not be useable (and not connected to a PHY). However, some
> device-trees may choose to still expose them (since their registers
> are present in the MMIO space) but with an "unused" property in them.
>
> Signed-off-by: Hugh Blemings <[EMAIL PROTECTED]>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Acked-by: Stefan Roese <[EMAIL PROTECTED]>

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add 405EX support to new EMAC driver

[Stefan Roese]

On Monday 05 November 2007, Benjamin Herrenschmidt wrote:
> > So how exactly do you want me to handle this (I'm still new to this
> > device
> > tree stuff, so please bear with me)? Like this?
> >
> > RGMII0: [EMAIL PROTECTED] {
> > device_type = "rgmii-interface";
> > compatible = "ibm,rgmii-405ex",
> > "ibm,rgmii";
> > reg = ;
> > has-mdio;
> > };
>
> The above.
>
> Properties without values are typically used for such "flags". I'll
> fixup the driver to also take that for the inverted STACR and will post
> a patch fixing that up asap.

OK, thanks. I'll wait with further 405ex emac patches until you changed this 
in the driver.

> > So perhaps most flexible would be to add individual properties,
> > like "stacr-oc-inverted" and "stacr-staopc-19-20". What do you think?
> > And
> > again the additional question: Should the be added as an new property
> > or
> > added to the compatible property?
>
> That's always the main question imho ... When it gets nasty like that I
> tend to think the compatible property is a good compromise. It's mostly
> a matter of taste. Unless you can come up with some more pleasant way to
> do it... maybe a stacr-type property with multiple values but it's
> really not worth complicating things when a compatible property will do
> the job just fine. In that case, it's not really a "feature" of a given
> implementation, but more about subtle differences between
> implementations.

OK.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add 405EX support to new EMAC driver

[Stefan Roese]

On Sunday 04 November 2007, Benjamin Herrenschmidt wrote:
> > Isn't this the case where there should really be device tree properties
> > instead? If you had an "ibm,emac-has-axon-stacr" property in the device
> > node, then you don't have to modify the driver for every new board out
> > there. Same for the other device properties, of course.
> >
> > I thought this was what having the device tree was all about. :(
>
> Somewhat yeah. There are subtle variations here or there we haven't
> totally indenfified... It might be a better option in our case here to
> add "has-mdio" to the rgmii nodes indeed.

So how exactly do you want me to handle this (I'm still new to this device 
tree stuff, so please bear with me)? Like this?

RGMII0: [EMAIL PROTECTED] {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii";
reg = ;
has-mdio;
};

Or add this to the compatible property?

RGMII0: [EMAIL PROTECTED] {
device_type = "rgmii-interface";
compatible = "ibm,rgmii-405ex", "ibm,rgmii", 
"ibm,has-mdio";
reg = ;
};

> Part of the problem with those cells is that the chip folks keep
> changing things subtly from one rev to another though, it's not even
> totally clear to me yet whether the RGMII registers are totally
> compatible betwee axon and 405ex, which is why I've pretty much stuck to
> "compatible" properties to identify the variants.
>
> The device-tree can do both. It's still better than no device-tree since
> at least you know what cell variant is in there.
>
> As for the STACR, Axon isn't the first one to have that bit flipped, I
> think we should name the property differently, something like
> "stacr-oc-inverted".

It's not only the OC bit-flip on AXON, but also the different STACR register 
layout for read/write op-codes (STAOPC). This seems to be the same on all new 
EMAC core's like on AXON, 440EPx/GRx and 405EX. So "stacr-oc-inverted" is not 
enough here. This is what is needed for 440SPe, which "only" has the bit-flip 
and the "old" STAOPC layout.

So perhaps most flexible would be to add individual properties, 
like "stacr-oc-inverted" and "stacr-staopc-19-20". What do you think? And 
again the additional question: Should the be added as an new property or 
added to the compatible property?

Please advise. Thanks.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: Add 405EX support to new EMAC driver

[Stefan Roese]

This patch adds support for the 405EX to the new EMAC driver. Some as on
AXON, the 405EX handles the MDIO via the RGMII bridge.

Tested on AMCC Kilauea.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/core.c  |3 ++-
 drivers/net/ibm_newemac/rgmii.c |   16 +++-
 drivers/net/ibm_newemac/rgmii.h |2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct 
emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
-   || of_device_is_compatible(np, "ibm,emac-440epx"))
+   || of_device_is_compatible(np, "ibm,emac-440epx")
+   || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..b9a4ce7 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,7 +140,12 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
 
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
 
-   if (dev->type != RGMII_AXON)
+   /*
+* Some platforms (e.g. 440GX) have RGMII support but don't use it for
+* MDIO access. Only continue if platforms is using MDIO over the RGMII
+* interface (e.g. AXON, 405EX).
+*/
+   if (dev->type != RGMII_HAS_MDIO)
return;
 
mutex_lock(&dev->lock);
@@ -161,7 +166,7 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
 
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
 
-   if (dev->type != RGMII_AXON)
+   if (dev->type != RGMII_HAS_MDIO)
return;
 
fer = in_be32(&p->fer);
@@ -251,8 +256,9 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
}
 
/* Check for RGMII type */
-   if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon"))
-   dev->type = RGMII_AXON;
+   if (of_device_is_compatible(ofdev->node, "ibm,rgmii-axon") ||
+   of_device_is_compatible(ofdev->node, "ibm,rgmii-405ex"))
+   dev->type = RGMII_HAS_MDIO;
else
dev->type = RGMII_STANDARD;
 
@@ -264,7 +270,7 @@ static int __devinit rgmii_probe(struct of_device *ofdev,
 
printk(KERN_INFO
   "RGMII %s %s initialized\n",
-  dev->type == RGMII_STANDARD ? "standard" : "axon",
+  dev->type == RGMII_STANDARD ? "standard" : "has-mdio",
   ofdev->node->full_name);
 
wmb();
diff --git a/drivers/net/ibm_newemac/rgmii.h b/drivers/net/ibm_newemac/rgmii.h
index 5780683..f1b0ef5 100644
--- a/drivers/net/ibm_newemac/rgmii.h
+++ b/drivers/net/ibm_newemac/rgmii.h
@@ -23,7 +23,7 @@
 
 /* RGMII bridge type */
 #define RGMII_STANDARD 0
-#define RGMII_AXON 1
+#define RGMII_HAS_MDIO 1
 
 /* RGMII bridge */
 struct rgmii_regs {
-- 
1.5.3.4.498.g9c514

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: Add 405EX support to new EMAC driver

[Stefan Roese]

On Thursday 01 November 2007, Josh Boyer wrote:
> > > - if (dev->type != RGMII_AXON)
> > > - return;
> > > -
> > >   mutex_lock(&dev->lock);
> >
> > That will break 440GX boards that need to use the RGMII for data and the
> > ZMII for MDIO.
> >
> > You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
> > instead and set that for 405EX as well instead.
>
> And perhaps adding a comment about that since the meaning of that code
> isn't very obvious. That way people that aren't the original author
> of the driver don't get confused again.

Will do. I'll send a fixed version tomorrow.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: Add 405EX support to new EMAC driver

[Stefan Roese]

This patch adds support for the 405EX to the new EMAC driver.

Tested on AMCC Kilauea.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
 drivers/net/ibm_newemac/core.c  |3 ++-
 drivers/net/ibm_newemac/rgmii.c |6 --
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct 
emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
-   || of_device_is_compatible(np, "ibm,emac-440epx"))
+   || of_device_is_compatible(np, "ibm,emac-440epx")
+   || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..e393f68 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
 
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
 
-   if (dev->type != RGMII_AXON)
-   return;
-
mutex_lock(&dev->lock);
 
fer = in_be32(&p->fer);
@@ -161,9 +158,6 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
 
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
 
-   if (dev->type != RGMII_AXON)
-   return;
-
fer = in_be32(&p->fer);
fer &= ~(0x0008u >> input);
out_be32(&p->fer, fer);
-- 
1.5.3.4.498.g9c514

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ibm_emac: Correctly detect old link speed

[Stefan Roese]

On Wednesday 16 May 2007, Eugene Surovegin wrote:
> On Wed, May 16, 2007 at 01:00:08PM +0200, Stefan Roese wrote:
> > This patch fixes a bug where the link speed change was not
> > detected correctly. This occured on a 440SPe (EMAC4) system
> > where the old link speed was 100Mbps and the new link speed
> > is 1000Mbps.
>
> Good catch, Stefan. Unfortunately, I have to NACK your patch - you
> broke non EMAC4 builds.

Yes, you're right of course.

> Correct fix is just to remove EMAC_MR1_MF_1000GPCS from the first
> if condition.

Yep.

> I'll send correct fix shortly along with other queued patches.

Thanks.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ibm_emac: Correctly detect old link speed

[Stefan Roese]

This patch fixes a bug where the link speed change was not
detected correctly. This occured on a 440SPe (EMAC4) system
where the old link speed was 100Mbps and the new link speed
is 1000Mbps.

Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>

---
commit 1e2a6085bbb6bd384e0812b6e9c62d18d14e1c0f
tree f441a914c9d66fb00fcde1e4bd7e02effba20dc7
parent 7b104bcb8e460e45a1aebe3da9b86aacdb4cab12
author Stefan Roese <[EMAIL PROTECTED]> Wed, 16 May 2007 12:54:40 +0200
committer Stefan Roese <[EMAIL PROTECTED]> Wed, 16 May 2007 12:54:40 +0200

 drivers/net/ibm_emac/ibm_emac_core.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ibm_emac/ibm_emac_core.c 
b/drivers/net/ibm_emac/ibm_emac_core.c
index 50035eb..ab38727 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -926,12 +926,18 @@ static int emac_link_differs(struct ocp_enet_private *dev)
int duplex = r & EMAC_MR1_FDE ? DUPLEX_FULL : DUPLEX_HALF;
int speed, pause, asym_pause;
 
-   if (r & (EMAC_MR1_MF_1000 | EMAC_MR1_MF_1000GPCS))
-   speed = SPEED_1000;
-   else if (r & EMAC_MR1_MF_100)
-   speed = SPEED_100;
-   else
-   speed = SPEED_10;
+   switch (r & EMAC_MR1_MF_MASK) {
+   case EMAC_MR1_MF_1000:
+   case EMAC_MR1_MF_1000GPCS:
+   speed = 1000;
+   break;
+   case EMAC_MR1_MF_10:
+   speed = 10;
+   break;
+   case EMAC_MR1_MF_100:
+   default:
+   speed = 100;
+   }
 
switch (r & (EMAC_MR1_EIFC | EMAC_MR1_APP)) {
case (EMAC_MR1_EIFC | EMAC_MR1_APP):
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

IEEE1588 Precision Time Protocol (PTP) driver for AMCC 405EZ

[Stefan Roese]

Hi all,

I'm in the stage of integrating an IEEE1588 PTP driver for the AMCC 405EZ PPC 
and looking for the correct location to place this driver in the Linux source 
tree. The driver is a character-driver that enables the user space 
applications to configure the time stamping unit and to read/write the 
timestamps.

Is "drivers/net/ptp" or "drivers/net/ieee1588" a good solution? Or should it 
go to "drivers/char/ptp" because of the chrdev nature of the driver?

Any suggestions welcome (could be that I missed an already existing example).

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)

[Stefan Roese]

On Saturday 24 December 2005 17:36, Marc Singer wrote:
> > > It most likely is the same code. Currently it's version 2.0. This
> > > version is available under a special Intel license
> > > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > > and under the BSD license (when you bug your Intel contact enough). The
> > > files seem to be the same, only the header with the license is
> > > exchanged.
> >
> > I'll take a look a this some more, but is it just the HAL or the whole
> > stack that's open?
>
> I chatted with Lennert about this and was, well, amazed.  In reading
> what I see on the web site, it looks to me that the library is still
> heavily guarded. They're publishing a GPL'd 'driver' that links with
> the library.

Yes, that's the ethernet driver using this access lib to communicate with the 
NPE's. This driver is published under the GPL.

> The click-through license establishes the same ol' terms.  "You can
> only distribute this software with a hardware product."
>
> Please show me where this new BSD license appears.

As far as I know, you can't find it on the Intel web site. As mentioned 
earlier, we (or our customer) had a lot of discussions with our Intel 
contacts, about getting a version of this access lib under a license allowing 
us to include it in GPL projects (U-Boot and Linux kernel). Finally we got 
access to this BSD version of this library, which seems to exist for quite 
some time. Please don't ask me why this version is not published officially 
by Intel.
 
Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)

[Stefan Roese]

On Saturday 24 December 2005 15:07, Deepak Saxena wrote:
> On Dec 21 2005, at 15:48, Stefan Roese was caught saying:
> > Hi Lennert,
> >
> > On Wednesday 21 December 2005 14:52, Lennert Buytenhek wrote:
> > > On Wed, Dec 21, 2005 at 01:00:34PM +0100, Stefan Roese wrote:
> > > > The main question I have is, where should the IXP4xx access-library
> > > > be located in the kernel directory structure?
> > >
> > > Maybe you can explain to the list readers what it is and what it does?
> >
> > It's the library needed for the NPE (network processor engines) ethernet
> > driver to access the on chip NPE's (e.g. download microcode, communicate
> > with the NPE's etc.). Unfortunately a pretty big piece of software
> > written to support multiple OS's. :-(
>
> As I mentioned in my earlier reply, we don't want all those abstractions
> in the kernel.

Understood. But a total rewrite of this code is unfortunately not an option, 
since it's just too much work (without a sponsor).

> > It most likely is the same code. Currently it's version 2.0. This version
> > is available under a special Intel license
> > (http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm)
> > and under the BSD license (when you bug your Intel contact enough). The
> > files seem to be the same, only the header with the license is exchanged.
>
> I'll take a look a this some more, but is it just the HAL or the whole
> stack that's open?

It's the complete ixp400 access library. The file available via the link above 
is called "IPL_ixp400AccessLibrary-2_0.zip" and the BSD version of it is 
called "BSD_ixp400AccessLibrary-2_0.zip". Only the license headers seem to be 
replaced. As I heard the 2.1 version should also be available in the BSD 
version in december, but I didn't get access to it until now.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)

[Stefan Roese]

Hi Lennert,

On Wednesday 21 December 2005 14:52, Lennert Buytenhek wrote:
> On Wed, Dec 21, 2005 at 01:00:34PM +0100, Stefan Roese wrote:
> > The main question I have is, where should the IXP4xx access-library
> > be located in the kernel directory structure?
>
> Maybe you can explain to the list readers what it is and what it does?

It's the library needed for the NPE (network processor engines) ethernet 
driver to access the on chip NPE's (e.g. download microcode, communicate with 
the NPE's etc.). Unfortunately a pretty big piece of software written to 
support multiple OS's. :-(

Until now, the access-library available under the special Intel license, 
didn't allow to build a kernel with an integrated NPE ethernet driver (and 
the access-library of course). The driver had to be built as module and 
loaded later. But even this usage doesn't seem correct regarding the GPL and 
Linus's statement of "derived work".

> If it's ixp4xx-specific, arch/arm/mach-ixp4xx might just be the best
> place.  The ixp2000 microengine loader was put into arch/arm/mach-ixp2000
> for mostly that reason (being ixp2000-specific), while the ethernet driver
> that uses that microengine loader will live under drivers/net/.
>
> > Please comment on this and let me know if such an effort has any chance
> > of getting accepted into the official kernel.
>
> Assuming that the license issues have all been worked out now, it'll
> mostly depend on the quality of the code.  (If this is the same Intel
> code that I saw a while ago, I think it'll need a fair amount of work
> before it can go in.)

It most likely is the same code. Currently it's version 2.0. This version is 
available under a special Intel license 
(http://www.intel.com/design/network/products/npfamily/ixp425swr1.htm) and 
under the BSD license (when you bug your Intel contact enough). The files 
seem to be the same, only the header with the license is exchanged.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Integrating IXP4xx NPE support in kernel (with IXP4xx accesslibrary)

[Stefan Roese]

I am trying to integrate the IXP4xx NPE ethernet support into the linux kernel 
(2.6).

Before you start, I know of the license problems with the IXP4xx software. We 
have a version of the Intel IXP4xx access-library licensed under the revised 
BSD license. So we should (hopefully) be able to integrate the software into 
the linux kernel.

The main question I have is, where should the IXP4xx access-library be located 
in the kernel directory structure? It's a pretty big piece of software. One 
idea is to use "arch/arm/mach-ixp4xx/accesslib" and place all files under 
this directory (since I don't want to "pollute" the drivers/net directory 
with this stuff). The NPE ethernet driver itself should of course be placed 
in drivers/net. Any other suggestions or remarks?

Please comment on this and let me know if such an effort has any chance of 
getting accepted into the official kernel.

Best regards,
Stefan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html