[PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
With introduction of common clock framework and the ability to provide gated clocks, mv643xx_eth required calls to get and enable these clock gates on some platforms. Back then, common clock framework api wasn't safe for architectures without support for common clocks. This has changed now and there are also managed (devm_) counterparts for clock related functions. The second patch in this series, also converts kzalloc to devm_kzalloc where applicable. Both patches have been sent to the corresponding mailing lists as individual patches before. To get the order required to apply them right, this patch set combines both patches into one set. Sebastian Hesselbarth (2): net: mv643xx_eth: add shared clk and cleanup existing clk handling net: mv643xx_eth: use managed devm_kzalloc Documentation/devicetree/bindings/marvell.txt |3 ++ drivers/net/ethernet/marvell/mv643xx_eth.c| 44 + 2 files changed, 18 insertions(+), 29 deletions(-) --- Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Lennert Buytenhek Cc: Sebastian Hesselbarth Cc: Andrew Lunn Cc: Jason Cooper Cc: Florian Fainelli Cc: Sergei Shtylyov Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: net...@vger.kernel.org -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] net: mv643xx_eth: add shared clk and cleanup existing clk handling
This patch adds an optional shared block clock to avoid lockups on
clock gated controllers. Besides the new clock, clock handling for
existing clocks is cleaned up and moved to devm_clk_get. Device
tree binding documentation is updated for the new clocks property.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Lennert Buytenhek
Cc: Sebastian Hesselbarth
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Florian Fainelli
Cc: Sergei Shtylyov
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: net...@vger.kernel.org
---
Documentation/devicetree/bindings/marvell.txt |3 +++
drivers/net/ethernet/marvell/mv643xx_eth.c| 27 ++---
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/marvell.txt
b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..f7a0da6 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -115,6 +115,9 @@ prefixed with the string "marvell,", for Marvell Technology
Group Ltd.
- compatible : "marvell,mv64360-eth-block"
- reg : Offset and length of the register set for this block
+ Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..bbe6104 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -268,7 +268,7 @@ struct mv643xx_eth_shared_private {
int extended_rx_coal_limit;
int tx_bw_control;
int tx_csum_limit;
-
+ struct clk *clk;
};
#define TX_BW_CONTROL_ABSENT 0
@@ -410,9 +410,7 @@ struct mv643xx_eth_private {
/*
* Hardware-specific parameters.
*/
-#if defined(CONFIG_HAVE_CLK)
struct clk *clk;
-#endif
unsigned int t_clk;
};
@@ -2569,6 +2567,10 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (msp->base == NULL)
goto out_free;
+ msp->clk = devm_clk_get(&pdev->dev, NULL);
+ if (!IS_ERR(msp->clk))
+ clk_prepare_enable(msp->clk);
+
/*
* (Re-)program MBUS remapping windows if we are asked to.
*/
@@ -2595,6 +2597,8 @@ static int mv643xx_eth_shared_remove(struct
platform_device *pdev)
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
iounmap(msp->base);
+ if (!IS_ERR(msp->clk))
+ clk_disable_unprepare(msp->clk);
kfree(msp);
return 0;
@@ -2801,13 +2805,12 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
* it to override the default.
*/
mp->t_clk = 13300;
-#if defined(CONFIG_HAVE_CLK)
- mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
+ mp->clk = devm_clk_get(&pdev->dev, NULL);
if (!IS_ERR(mp->clk)) {
clk_prepare_enable(mp->clk);
mp->t_clk = clk_get_rate(mp->clk);
}
-#endif
+
set_params(mp, pd);
netif_set_real_num_tx_queues(dev, mp->txq_count);
netif_set_real_num_rx_queues(dev, mp->rxq_count);
@@ -2889,12 +2892,8 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
return 0;
out:
-#if defined(CONFIG_HAVE_CLK)
- if (!IS_ERR(mp->clk)) {
+ if (!IS_ERR(mp->clk))
clk_disable_unprepare(mp->clk);
- clk_put(mp->clk);
- }
-#endif
free_netdev(dev);
return err;
@@ -2909,12 +2908,8 @@ static int mv643xx_eth_remove(struct platform_device
*pdev)
phy_detach(mp->phy);
cancel_work_sync(&mp->tx_timeout_task);
-#if defined(CONFIG_HAVE_CLK)
- if (!IS_ERR(mp->clk)) {
+ if (!IS_ERR(mp->clk))
clk_disable_unprepare(mp->clk);
- clk_put(mp->clk);
- }
-#endif
free_netdev(mp->dev);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] net: mv643xx_eth: use managed devm_kzalloc
This patch moves shared private data kzalloc to managed devm_kzalloc and
cleans now unneccessary kfree and error handling.
Signed-off-by: Sebastian Hesselbarth
---
Changes from v1:
- replaced EADDRNOTAVAIL with ENOMEM on failing ioremap (Reported by
Sergei Shtylyov)
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Lennert Buytenhek
Cc: Sebastian Hesselbarth
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Florian Fainelli
Cc: Sergei Shtylyov
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index bbe6104..305038f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2547,25 +2547,22 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
- int ret;
if (!mv643xx_eth_version_printed++)
pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
mv643xx_eth_driver_version);
- ret = -EINVAL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
- goto out;
+ return -EINVAL;
- ret = -ENOMEM;
- msp = kzalloc(sizeof(*msp), GFP_KERNEL);
+ msp = devm_kzalloc(&pdev->dev, sizeof(*msp), GFP_KERNEL);
if (msp == NULL)
- goto out;
+ return -ENOMEM;
msp->base = ioremap(res->start, resource_size(res));
if (msp->base == NULL)
- goto out_free;
+ return -ENOMEM;
msp->clk = devm_clk_get(&pdev->dev, NULL);
if (!IS_ERR(msp->clk))
@@ -2585,11 +2582,6 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, msp);
return 0;
-
-out_free:
- kfree(msp);
-out:
- return ret;
}
static int mv643xx_eth_shared_remove(struct platform_device *pdev)
@@ -2599,7 +2591,6 @@ static int mv643xx_eth_shared_remove(struct
platform_device *pdev)
iounmap(msp->base);
if (!IS_ERR(msp->clk))
clk_disable_unprepare(msp->clk);
- kfree(msp);
return 0;
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net: mv643xx_eth: Add GRO support
This patch adds GRO support to mv643xx_eth by making it invoke napi_gro_receive instead of netif_receive_skb. Signed-off-by: Soeren Moch Signed-off-by: Sebastian Hesselbarth --- Cc: "David S. Miller" Cc: Lennert Buytenhek Cc: Andrew Lunn Cc: Jason Cooper Cc: Florian Fainelli Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Dale Farnsworth Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index 305038f..c850d04 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget) lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts); lro_flush_needed = 1; } else - netif_receive_skb(skb); + napi_gro_receive(&mp->napi, skb); continue; -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
On Thu, Apr 11, 2013 at 3:13 PM, Willy Tarreau wrote: > On Thu, Apr 11, 2013 at 02:40:23PM +0200, Sebastian Hesselbarth wrote: >> This patch adds GRO support to mv643xx_eth by making it invoke >> napi_gro_receive instead of netif_receive_skb. >> >> Signed-off-by: Soeren Moch >> Signed-off-by: Sebastian Hesselbarth >> --- >> Cc: "David S. Miller" >> Cc: Lennert Buytenhek >> Cc: Andrew Lunn >> Cc: Jason Cooper >> Cc: Florian Fainelli >> Cc: Benjamin Herrenschmidt >> Cc: Paul Mackerras >> Cc: Dale Farnsworth >> Cc: net...@vger.kernel.org >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: linuxppc-dev@lists.ozlabs.org >> Cc: linux-ker...@vger.kernel.org >> --- >> drivers/net/ethernet/marvell/mv643xx_eth.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c >> b/drivers/net/ethernet/marvell/mv643xx_eth.c >> index 305038f..c850d04 100644 >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c >> @@ -604,7 +604,7 @@ static int rxq_process(struct rx_queue *rxq, int budget) >> lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts); >> lro_flush_needed = 1; >> } else >> - netif_receive_skb(skb); >> + napi_gro_receive(&mp->napi, skb); >> >> continue; > > I remember having experimented with this on 3.6 a few months ago with this > driver and finally switching back to something like this instead which > showed better performance on my tests : > >if (skb->ip_summed == CHECKSUM_UNNECESSARY) >napi_gro_receive(napi, skb); >else >netif_receive_skb(skb); > > Unfortunately I don't have more details as my commit message was rather > short due to this resulting from experimentation. Did you verify that > you did not lose any performance in various workloads ? I was playing > with bridges at this time, it's possible that I got better performance > on bridging with netif_receive_skb() than with napi_gro_receive(). Hi Willy, I did some simple tests on Dove/Cubox with 'netperf -cCD' and gso/gro/lro options on mv643xx_eth. The tests may not be sufficient, as I am not that into net performance testing. I tried todays net-next on top of 3.9-rc6 without any gro patch, with the initial patch (Soeren) and your proposed patch (Willy). The results show that both patches allow a significant increase in throughput compared to netif_receive_skb (!gro, !lro) alone. Having gro with lro disabled gives some 2% more throughput compared to lro only. Sebastian Recv SendSend Utilization Service Demand Socket Socket Message Elapsed Send Recv SendRecv Size SizeSize Time Throughput localremote local remote bytes bytes bytessecs.10^6bits/s % S % S us/KB us/KB 87380 16384 1638410.02 615.65 19.1599.905.097 13.293 (3.9-rc6: gso) 87380 16384 1638410.02 615.82 19.0599.905.067 13.289 (3.9-rc6: gso, gro) 87380 16384 1638410.03 747.44 23.1799.805.079 10.938 (3.9-rc6: gso, lro) 87380 16384 1638410.02 745.28 22.5799.804.963 10.970 (3.9.rc6: gso, gro, lro) 87380 16384 1638410.02 600.34 19.1099.905.211 13.632 (3.9-rc6+soeren: gso) 87380 16384 1638410.02 764.23 23.4299.805.021 10.698 (3.9-rc6+soeren: gso, gro) 87380 16384 1638410.02 749.81 23.1399.805.055 10.904 (3.9-rc6+soeren: gso, lro) 87380 16384 1638410.02 745.84 22.3499.804.907 10.962 (3.9.rc6+soeren: gso, gro, lro) 87380 16384 1638410.02 605.79 18.79100.00 5.082 13.523 (3.9-rc6+willy: gso) 87380 16384 1638410.02 765.64 24.6899.805.281 10.678 (3.9-rc6+willy: gso, gro) 87380 16384 1638410.02 750.30 26.0299.805.682 10.897 (3.9-rc6+willy: gso, lro) 87380 16384 1638410.03 749.40 21.8699.804.778 10.910 (3.9.rc6+willy: gso, gro, lro) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau wrote: > On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote: >> I tried todays net-next on top of 3.9-rc6 without any gro patch, with >> the initial >> patch (Soeren) and your proposed patch (Willy). The results show that >> both patches >> allow a significant increase in throughput compared to >> netif_receive_skb (!gro, !lro) >> alone. Having gro with lro disabled gives some 2% more throughput >> compared to lro only. > > Indeed this is consistent with my memories, since Eric improved the > GRO path, it became faster than LRO on this chip. I don't have a strong opinion on whether Soeren's or your proposal should be submitted. But I insist on having one of them in, as GRO significantly improves the common use case, is enabled by default, and not as constrained as LRO. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
On Thu, Apr 11, 2013 at 5:32 PM, Willy Tarreau wrote: > On Thu, Apr 11, 2013 at 05:27:03PM +0200, Sebastian Hesselbarth wrote: >> I don't have a strong opinion on whether Soeren's or your proposal should >> be submitted. But I insist on having one of them in, as GRO significantly >> improves the common use case, is enabled by default, and not as >> constrained as LRO. > > I agree, use yours first, but we should keep an eye on this. Since you have > everything to run a test, please try to see if you can get netperf to run > over IPv6, I'm sure the NIC doesn't handle it. Willy, out of curiosity I replayed all tests using netperf/netserver with -6 which enables ipv6. The overall results remain quite the same here: enabling support for GRO gives a huge improvement in achievable throughput, and the difference between Soeren's and your patch is neglectible. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
On 04/11/2013 07:55 PM, Ben Hutchings wrote: On Thu, 2013-04-11 at 14:40 +0200, Sebastian Hesselbarth wrote: This patch adds GRO support to mv643xx_eth by making it invoke napi_gro_receive instead of netif_receive_skb. The inet_lro support should be removed at the same time; inet_lro is now deprecated and there should be no need to keep both of them. Ben, I agree on removing it asap, but I also like to see GRO support in. Maybe, we postpone lro removal just a little bit. I have just started to look at mv643xx_eth and remember Marvell Orion SoCs are not the only platform using it. I haven't heard a single word from ppc guys, yet. Willy just posted an experimental patch to remove lro. I'll have a look at it and test it out on Dove. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net: mv643xx_eth: remove deprecated inet_lro support
With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.
Signed-off-by: Sebastian Hesselbarth
Based-on-patch-by: Eric Dumazet
Based-on-patch-by: Willy Tarreau
---
Note: This patch is based upon recent cleanup patches and GRO support
patch for mv643xx_eth.
Cc: "David S. Miller"
Cc: Lennert Buytenhek
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Florian Fainelli
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Dale Farnsworth
Cc: Ben Hutchings
Cc: Soeren Moch
Cc: Eric Dumazet
Cc: Willy Tarreau
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +---
1 file changed, 3 insertions(+), 94 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
@@ -316,12 +316,6 @@ struct mib_counters {
u32 rx_overrun;
};
-struct lro_counters {
- u32 lro_aggregated;
- u32 lro_flushed;
- u32 lro_no_desc;
-};
-
struct rx_queue {
int index;
@@ -335,9 +329,6 @@ struct rx_queue {
dma_addr_t rx_desc_dma;
int rx_desc_area_size;
struct sk_buff **rx_skb;
-
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_arr[8];
};
struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
- struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
}
-
-/* rx napi **/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
- u64 *hdr_flags, void *priv)
-{
- unsigned long cmd_sts = (unsigned long)priv;
-
- /*
-* Make sure that this packet is Ethernet II, is not VLAN
-* tagged, is IPv4, has a valid IP header, and is TCP.
-*/
- if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
- RX_PKT_IS_VLAN_TAGGED)) !=
- (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
- return -1;
-
- skb_reset_network_header(skb);
- skb_set_transport_header(skb, ip_hdrlen(skb));
- *iphdr = ip_hdr(skb);
- *tcph = tcp_hdr(skb);
- *hdr_flags = LRO_IPV4 | LRO_TCP;
-
- return 0;
-}
-
static int rxq_process(struct rx_queue *rxq, int budget)
{
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = &mp->dev->stats;
- int lro_flush_needed;
int rx;
- lro_flush_needed = 0;
rx = 0;
while (rx < budget && rxq->rx_desc_count) {
struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, mp->dev);
- if (skb->dev->features & NETIF_F_LRO &&
- skb->ip_summed == CHECKSUM_UNNECESSARY) {
- lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
- lro_flush_needed = 1;
- } else
- napi_gro_receive(&mp->napi, skb);
+ napi_gro_receive(&mp->napi, skb);
continue;
@@ -624,9 +578,6 @@ err:
dev_kfree_skb(skb);
}
- if (lro_flush_needed)
- lro_flush_all(&rxq->lro_mgr);
-
if (rx < budget)
mp->work_rx &= ~(1 << rxq->index);
@@ -1118,26 +1069,6 @@ static struct net_device_stats
*mv643xx_eth_get_stats(struct net_device *dev)
return stats;
}
-static void mv643xx_eth_grab_lro_stats(struct mv643xx_eth_private *mp)
-{
- u32 lro_aggregated = 0;
- u32 lro_flushed = 0;
- u32 lro_no_desc = 0;
- int i;
-
- for (i = 0; i < mp->rxq_count; i++) {
- struct rx_queue *rxq = mp->rxq + i;
-
- lro_aggregated += rxq->lro_mgr.stats.aggregated;
- lro_flushed += rxq->lro_mgr.stats.flushed;
- lro_no_desc += rxq->lro_mgr.stats.no_desc;
Re: [PATCH] net: mv643xx_eth: remove deprecated inet_lro support
On 04/11/2013 09:46 PM, Eric Dumazet wrote: On Thu, 2013-04-11 at 21:11 +0200, Sebastian Hesselbarth wrote: With recent support for GRO, there is no need to keep both LRO and GRO. This patch therefore removes the deprecated inet_lro support from mv643xx_eth. This is work is based on an experimental patch provided by Eric Dumazet and Willy Tarreau. Signed-off-by: Sebastian Hesselbarth Based-on-patch-by: Eric Dumazet Based-on-patch-by: Willy Tarreau --- Note: This patch is based upon recent cleanup patches and GRO support patch for mv643xx_eth. Cc: "David S. Miller" Cc: Lennert Buytenhek Cc: Andrew Lunn Cc: Jason Cooper Cc: Florian Fainelli Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Dale Farnsworth Cc: Ben Hutchings Cc: Soeren Moch Cc: Eric Dumazet Cc: Willy Tarreau Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +--- 1 file changed, 3 insertions(+), 94 deletions(-) Seems fine to me, but you also could remove "select INET_LRO" from drivers/net/ethernet/marvell/Kconfig Ok, I will wait for tomorrow to see if there are more objections and respin a v2. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support
With recent support for GRO, there is no need to keep both LRO and
GRO. This patch therefore removes the deprecated inet_lro support
from mv643xx_eth. This is work is based on an experimental patch
provided by Eric Dumazet and Willy Tarreau.
Signed-off-by: Sebastian Hesselbarth
Based-on-patch-by: Eric Dumazet
Based-on-patch-by: Willy Tarreau
---
Changes from v1:
- also remove INET_LRO from Kconfig (Reported by Eric Dumazet)
Cc: "David S. Miller"
Cc: Lennert Buytenhek
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Florian Fainelli
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Dale Farnsworth
Cc: Ben Hutchings
Cc: Soeren Moch
Cc: Eric Dumazet
Cc: Willy Tarreau
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/Kconfig |1 -
drivers/net/ethernet/marvell/mv643xx_eth.c | 97 +---
2 files changed, 3 insertions(+), 95 deletions(-)
diff --git a/drivers/net/ethernet/marvell/Kconfig
b/drivers/net/ethernet/marvell/Kconfig
index 5170ecb..0051f0e 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -21,7 +21,6 @@ if NET_VENDOR_MARVELL
config MV643XX_ETH
tristate "Marvell Discovery (643XX) and Orion ethernet support"
depends on (MV64X60 || PPC32 || PLAT_ORION) && INET
- select INET_LRO
select PHYLIB
select MVMDIO
---help---
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c850d04..d0afeea 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -56,8 +56,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
@@ -316,12 +316,6 @@ struct mib_counters {
u32 rx_overrun;
};
-struct lro_counters {
- u32 lro_aggregated;
- u32 lro_flushed;
- u32 lro_no_desc;
-};
-
struct rx_queue {
int index;
@@ -335,9 +329,6 @@ struct rx_queue {
dma_addr_t rx_desc_dma;
int rx_desc_area_size;
struct sk_buff **rx_skb;
-
- struct net_lro_mgr lro_mgr;
- struct net_lro_desc lro_arr[8];
};
struct tx_queue {
@@ -373,8 +364,6 @@ struct mv643xx_eth_private {
spinlock_t mib_counters_lock;
struct mib_counters mib_counters;
- struct lro_counters lro_counters;
-
struct work_struct tx_timeout_task;
struct napi_struct napi;
@@ -503,42 +492,12 @@ static void txq_maybe_wake(struct tx_queue *txq)
}
}
-
-/* rx napi **/
-static int
-mv643xx_get_skb_header(struct sk_buff *skb, void **iphdr, void **tcph,
- u64 *hdr_flags, void *priv)
-{
- unsigned long cmd_sts = (unsigned long)priv;
-
- /*
-* Make sure that this packet is Ethernet II, is not VLAN
-* tagged, is IPv4, has a valid IP header, and is TCP.
-*/
- if ((cmd_sts & (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
- RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_MASK |
- RX_PKT_IS_VLAN_TAGGED)) !=
- (RX_IP_HDR_OK | RX_PKT_IS_IPV4 |
-RX_PKT_IS_ETHERNETV2 | RX_PKT_LAYER4_TYPE_TCP_IPV4))
- return -1;
-
- skb_reset_network_header(skb);
- skb_set_transport_header(skb, ip_hdrlen(skb));
- *iphdr = ip_hdr(skb);
- *tcph = tcp_hdr(skb);
- *hdr_flags = LRO_IPV4 | LRO_TCP;
-
- return 0;
-}
-
static int rxq_process(struct rx_queue *rxq, int budget)
{
struct mv643xx_eth_private *mp = rxq_to_mp(rxq);
struct net_device_stats *stats = &mp->dev->stats;
- int lro_flush_needed;
int rx;
- lro_flush_needed = 0;
rx = 0;
while (rx < budget && rxq->rx_desc_count) {
struct rx_desc *rx_desc;
@@ -599,12 +558,7 @@ static int rxq_process(struct rx_queue *rxq, int budget)
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, mp->dev);
- if (skb->dev->features & NETIF_F_LRO &&
- skb->ip_summed == CHECKSUM_UNNECESSARY) {
- lro_receive_skb(&rxq->lro_mgr, skb, (void *)cmd_sts);
- lro_flush_needed = 1;
- } else
- napi_gro_receive(&mp->napi, skb);
+ napi_gro_receive(&mp->napi, skb);
continue;
@@ -624,9 +578,6 @@ err:
dev_kfree_skb(skb);
}
- if (lro_flush_needed)
- lro_flush_all(&rxq->lro_mgr);
-
if (rx < budget)
mp->work_rx &= ~(1 << rxq->index);
@@ -1118,26 +1069,6 @@ static struct net_device_stats
*mv643xx_et
[PATCH v4 01/12] net: mv643xx_eth: use phy_disconnect instead of phy_detach
Using a separated mdio bus driver with mvmdio, phy_detach on network device
removal will not stop the phy and finally lead to NULL pointer dereference
in mvmdio due to non-existent network device. Use phy_disconnect instead
to properly stop phy device from accessing network device prior removal of
the network device.
Signed-off-by: Sebastian Hesselbarth
---
Note: I observed this behavior when removing a modular mv643xx_eth driver
after attaching it to a phy handled by (also modular) mvmdio. The mvmdio
conversion has been done in
commit c3a07134e6aa5b93a37f72ffa3d11fadf72bf757
("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
and should go back any -stable version with that commit (propably only 3.9)
@David: I am not sure if the above description is sufficient for a -stable
patch, if you need more, like actual kernel failure, I am sure I can reproduce
it.
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index d0afeea..ef3454c 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2805,7 +2805,7 @@ static int mv643xx_eth_remove(struct platform_device
*pdev)
unregister_netdev(mp->dev);
if (mp->phy != NULL)
- phy_detach(mp->phy);
+ phy_disconnect(mp->phy);
cancel_work_sync(&mp->tx_timeout_task);
if (!IS_ERR(mp->clk))
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 02/12] net: mv643xx_eth: use managed devm_ioremap for port registers
Make use of managed devm_ioremap and remove corresponding iounmap.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index ef3454c..e658ebd 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2470,7 +2470,7 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (msp == NULL)
return -ENOMEM;
- msp->base = ioremap(res->start, resource_size(res));
+ msp->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (msp->base == NULL)
return -ENOMEM;
@@ -2498,7 +2498,6 @@ static int mv643xx_eth_shared_remove(struct
platform_device *pdev)
{
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
- iounmap(msp->base);
if (!IS_ERR(msp->clk))
clk_disable_unprepare(msp->clk);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 03/12] net: mv643xx_eth: add phy_node to platform_data struct
This adds a struct device_node pointer for a phy passed by phandle
to mv643xx_eth node.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
include/linux/mv643xx_eth.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 141d395..6e8215b 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -30,6 +30,7 @@ struct mv643xx_eth_shared_platform_data {
#define MV643XX_ETH_PHY_ADDR(x)(0x80 | (x))
#define MV643XX_ETH_PHY_NONE 0xff
+struct device_node;
struct mv643xx_eth_platform_data {
/*
* Pointer back to our parent instance, and our port number.
@@ -41,6 +42,7 @@ struct mv643xx_eth_platform_data {
* Whether a PHY is present, and if yes, at which address.
*/
int phy_addr;
+ struct device_node *phy_node;
/*
* Use this MAC address if it is valid, overriding the
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 00/12] net: mv643xx_eth DT support and fixes
This patch set picks up work by Florian Fainelli bringing full DT
support to mv643xx_eth and Marvell SoCs using it.
The current v4 patch set drops 1:1 compatibiliy with PPC binding
for two reasons:
(a) PPC parses DT nodes in arch/ppc/sysdev and creates non-DT
platform_devices itself,
(b) property and node naming for new ethernet devices is slightly
different ("phy" vs "phy-handle", "marvell," prefix)
Anyway, the two bindings are functionally compatible and PPC bindings
can be converted if desireable. The patch set if fully bisectable and
care has been taken to (a) not reparse on PPC platforms, (b) allow to
use platform_device based registration even if on CONFIG_OF. Not tested
is double registration issues, i.e. if DT nodes are provided but legacy
registration it not yet removed. This double registration should lead
to either non-DT or DT registered device fail on already claimed
ressources.
Also this patch set picks up the opportunity to fix some repeatedly
reported issues with modular mvmdio/mv643xx_eth loading, unloading,
and reloading. It has been tested on SolidRun CuBox (Dove) and
Seagate Dockstar (Kirkwood) so far.
Patch 1 fixes an issue introduced with switch to separate mvmdio
driver, where detaching mv643xx_eth from a phy will not stop the
phy state machine and finally dereference the already removed network
device. Using phy_disconnect properly stops the phy state machine
before detaching from it. Perhaps, this patch should go back in
stable (most likely 3.9 only) if mvmdio separation patch went in
there.
Patch 2 makes use of managed devm_ioremap for the last remaining
non-managed resource.
Patches 3-4 prepare DT support for mv643xx_eth by adding a phy_node
pointer to platform_data and exploiting that phy_node when attaching
to a phy.
Patch 5 introduces DT parsing support for mv643xx_eth by adding a
match table to the shared driver and adding a platform_device for
each of its child nodes.
Patches 6-8 add corresponding device tree nodes to Marvell Dove,
Kirkwood, and Orion5x including all boards. Where known, also
the PHY compatible string has been set to what is reported in the
boards boot loader.
Patches 9, 10-11, and 12 finally remove all legacy platform_device
based registration from Dove, Kirkwood, and Orion5x DT setup. For
Kirkwood also now obsolete board specific setup is removed from
common DT board setup, Kconfig, Makefile, and kirkwood_defconfig.
For the patches above I suggest to take Patches 1-5 through David
Miller's branch, and Patches 6-12 through Jason Cooper's when they
have appeared on mainline linux. The patch set has been based on
todays net-next, if I shall rebase them on any other branch please
name it.
Sebastian Hesselbarth (12):
net: mv643xx_eth: use phy_disconnect instead of phy_detach
net: mv643xx_eth: use managed devm_ioremap for port registers
net: mv643xx_eth: add phy_node to platform_data struct
net: mv643xx_eth: use of_phy_connect if phy_node present
net: mv643xx_eth: add DT parsing support
ARM: dove: add gigabit ethernet and mvmdio device tree nodes
ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
ARM: dove: remove legacy mv643xx_eth setup
ARM: kirkwood: remove legacy clk alias for mv643xx_eth
ARM: kirkwood: remove redundant DT board files
ARM: orion5x: remove legacy mv643xx_eth board setup
.../devicetree/bindings/net/marvell-orion-net.txt | 83 +
arch/arm/boot/dts/dove-cubox.dts |7 +
arch/arm/boot/dts/dove.dtsi| 35
arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-dockstar.dts| 17 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30
arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++
arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +++
arch/arm/boot/dts/kirkwood-is2.dts |2 +
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 +++
.../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 16 ++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-ns2.dts |2 +
arch/arm/boot/dts/kirkwood-ns2lite.dts |2 +
arch/arm/boot/dts/kirkwood-ns2max.dts |2 +
arch/arm/boot/dts/kirkwood-ns2mini.dts |2 +
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 16 ++
arch/arm/boot/dts/kirkwood-topkick.dts | 16 ++
arch/arm/boot/dts/kirkwood-ts219-6281.d
[PATCH v4 04/12] net: mv643xx_eth: use of_phy_connect if phy_node present
This connects to a phy node passed to the port device instead of probing
the phy by phy_addr.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index e658ebd..0f5c3c2 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
static char mv643xx_eth_driver_name[] = "mv643xx_eth";
static char mv643xx_eth_driver_version[] = "1.4";
@@ -2715,17 +2716,27 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
netif_set_real_num_tx_queues(dev, mp->txq_count);
netif_set_real_num_rx_queues(dev, mp->rxq_count);
- if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
+ err = 0;
+ if (pd->phy_node) {
+ mp->phy = of_phy_connect(mp->dev, pd->phy_node,
+mv643xx_eth_adjust_link, 0,
+PHY_INTERFACE_MODE_GMII);
+ if (!mp->phy)
+ err = -ENODEV;
+ } else if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
mp->phy = phy_scan(mp, pd->phy_addr);
- if (IS_ERR(mp->phy)) {
+ if (IS_ERR(mp->phy))
err = PTR_ERR(mp->phy);
- if (err == -ENODEV)
- err = -EPROBE_DEFER;
- goto out;
- }
- phy_init(mp, pd->speed, pd->duplex);
+ else
+ phy_init(mp, pd->speed, pd->duplex);
}
+ if (err == -ENODEV) {
+ err = -EPROBE_DEFER;
+ goto out;
+ }
+ if (err)
+ goto out;
SET_ETHTOOL_OPS(dev, &mv643xx_eth_ethtool_ops);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v3->v4:
- convert to new device tree binding
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/dove-cubox.dts |7 +++
arch/arm/boot/dts/dove.dtsi | 35 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 7e3065a..02618fa 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -49,6 +49,13 @@
&uart0 { status = "okay"; };
&sata0 { status = "okay"; };
&i2c0 { status = "okay"; };
+&mdio { status = "okay"; };
+ð { status = "okay"; };
+
+ðphy {
+ compatible = "marvell,88e1310";
+ reg = <1>;
+};
&sdio0 {
status = "okay";
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..8612658 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,40 @@
dmacap,xor;
};
};
+
+ mdio: mdio-bus@72004 {
+ compatible = "marvell,orion-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72004 0x84>;
+ interrupts = <30>;
+ clocks = <&gate_clk 2>;
+ status = "disabled";
+
+ ethphy: ethernet-phy {
+ device-type = "ethernet-phy";
+ /* set phy address in board file */
+ };
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x4000>;
+ clocks = <&gate_clk 2>;
+ marvell,tx-checksum-limit = <1600>;
+ status = "disabled";
+
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg = <0>;
+ interrupts = <29>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <ðphy>;
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 05/12] net: mv643xx_eth: add DT parsing support
This adds device tree parsing support for the shared driver of mv643xx_eth.
As the bindings are slightly different from current PPC bindings new binding
documentation is also added. Following PPC-style device setup, the shared
driver now also adds port platform_devices and sets up port platform_data.
Signed-off-by: Sebastian Hesselbarth
---
Note: Although different, device tree bindings are compatible with PPC
bindings. As I do not have access to any PPC platform using mv643xx_eth,
I leave conversion ("phy" vs "phy-handle") and compatible string name
up to PPC guys.
Due to hang reports for modular built mvmdio and mv643xx_eth, I have
tested module loading/unloading/reloading on CuBox (Dove) and Dockstar
(Kirkwood) without any issues for the whole patch set.
Changelog:
v3->v4:
- separation of independent patches (phy, of_mdio, devm)
- stand-alone device tree binding compatible to existing mv64x60 binding
- device node match for shared driver only
- device node registration for port drivers
- properly return -EPROBE_DEFER on missing of phy (Reported by Simon Baatz)
v2->v3:
- rebase on top of mv643xx_eth clean-ups
- do not reparse existing platform_data
- use managed devm_kzalloc for parsed platform_data
- use of_property_read_u32 where applicable
- add phy_node to platform_data
- use of_connect_phy if DT phy node was found
v1->v2:
- properly ifdef of_platform_bus_probe with CONFIG_OF
- handle of_platform_bus_probe errors and cleanup accordingly
- use of_property_read_u32 where applicable
- parse "duplex" and "speed" property in PHY-less configuration
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../devicetree/bindings/net/marvell-orion-net.txt | 83 +++
drivers/net/ethernet/marvell/mv643xx_eth.c | 152 +++-
2 files changed, 231 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/marvell-orion-net.txt
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
new file mode 100644
index 000..23ffd57
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -0,0 +1,83 @@
+Marvell Orion/Discovery ethernet controller
+=
+
+The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
+(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
+Discovery system controller chips (mv64[345]60).
+
+The Discovery ethernet controller is described with two levels of nodes. The
+first level describes the ethernet controller itself and the second level
+describes up to 3 ethernet port nodes within that controller. The reason for
+the multiple levels is that the port registers are interleaved within a single
+set of controller registers. Each port node describes port-specific properties.
+
+Note: The above separation is only true for Discovery system controllers.
+For Orion SoCs we stick to the separation, although there each controller has
+only one port associated. Multiple ports are implemented as multiple
single-port
+controllers.
+
+* Ethernet controller node
+
+Required controller properties:
+ - #address-cells: shall be 1.
+ - #size-cells: shall be 0.
+ - compatible: shall be "marvell,orion-eth".
+ - reg: address and length of the controller registers.
+
+Optional controller properties:
+ - clocks: phandle reference to the controller clock.
+ - marvell,tx-checksum-limit: max tx packet size for hardware checksum.
+
+* Ethernet port node
+
+Required port properties:
+ - device_type: shall be "network".
+ - compatible: shall be "marvell,orion-eth-port".
+ - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
+ - interrupts: port interrupt.
+ - local-mac-address: 6 bytes MAC address.
+
+Optional port properties:
+ - marvell,tx-queue-size: size of the transmit ring buffer.
+ - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
+ - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
+ - marvell,rx-queue-size: size of the receive ring buffer.
+ - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
+ - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
+
+and
+
+ - phy-handle: phandle reference to ethernet PHY.
+
+or
+
+ - speed: port speed if no PHY connected.
+ - duplex: port mode if no PHY connected.
+
+* Node example:
+
+mdio-bus {
+ ...
+ ethphy: ethernet-phy@8 {
+ device_type = "ethernet-phy";
+ ...
+ };
+};
+
+eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-ce
[PATCH v4 07/12] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v3->v4:
- convert to new device tree binding
- fix phy addr of kirkwood-ts219-6282.dts (Reported by Andrew Lunn)
- fix mvmdio interrupt (Reported by Simon Baatz)
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-dockstar.dts| 17 +++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30 +++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++
arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +
arch/arm/boot/dts/kirkwood-is2.dts |2 +
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 ++
.../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 16 ++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-ns2.dts |2 +
arch/arm/boot/dts/kirkwood-ns2lite.dts |2 +
arch/arm/boot/dts/kirkwood-ns2max.dts |2 +
arch/arm/boot/dts/kirkwood-ns2mini.dts |2 +
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 16 ++
arch/arm/boot/dts/kirkwood-topkick.dts | 16 ++
arch/arm/boot/dts/kirkwood-ts219-6281.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219-6282.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 16 ++
arch/arm/boot/dts/kirkwood.dtsi| 52
25 files changed, 398 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts
b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 5f21d4e..03e1b68 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -87,3 +87,19 @@
gpios = <&gpio0 17 0>;
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 6875ac0..7c8bc17 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -217,3 +217,19 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@8 {
+ device_type = "ethernet-phy";
+ reg = <8>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts
b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 0196cf6..b5aebbc 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -91,3 +91,20 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ compatible = "marvell,88e1116";
+ reg = <0>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 289e51d..e0c93d4 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+
+ ethphy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
+
+ð1 {
+ status = "okay";
+ ethernet1-port@0 {
+
[PATCH v4 08/12] ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Orion5x boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v3->v4:
- convert to new device tree binding
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../dts/orion5x-lacie-ethernet-disk-mini-v2.dts| 17
arch/arm/boot/dts/orion5x.dtsi | 29
2 files changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
index 0077fc8..c7e2efd 100644
--- a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
+++ b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
@@ -53,3 +53,20 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ðphy: ethernet-phy {
+ device-type = "ethernet-phy";
+ reg = <8>;
+ };
+};
+
+ð {
+ status = "okay";
+
+ ethernet-port@0 {
+ phy-handle = <ðphy>;
+ };
+};
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 892c64e..6fe45d5 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -132,5 +132,34 @@
interrupts = <28>;
status = "okay";
};
+
+ mdio: mdio-bus@72004 {
+ compatible = "marvell,orion-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72004 0x84>;
+ interrupts = <22>;
+ status = "disabled";
+
+ /* add phy nodes in board file */
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x4000>;
+ marvell,tx-checksum-limit = <1600>;
+ status = "disabled";
+
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg = <0>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ /* set phy-handle property in board file */
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 09/12] ARM: dove: remove legacy mv643xx_eth setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards anymore.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-dove/board-dt.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 0b14280..048e942 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -34,10 +34,6 @@ static void __init dove_legacy_clk_init(void)
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CLOCK_GATING_BIT_GBE;
- orion_clkdev_add(NULL, "mv643xx_eth_port.0",
-of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
orion_clkdev_add("0", "pcie",
of_clk_get_from_provider(&clkspec));
@@ -53,10 +49,6 @@ static void __init dove_of_clk_init(void)
dove_legacy_clk_init();
}
-static struct mv643xx_eth_platform_data dove_dt_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
-};
-
static void __init dove_dt_init(void)
{
pr_info("Dove 88AP510 SoC\n");
@@ -70,7 +62,6 @@ static void __init dove_dt_init(void)
dove_of_clk_init();
/* Internal devices not ported to DT yet */
- dove_ge00_init(&dove_dt_ge00_data);
dove_pcie_init(1, 1);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 10/12] ARM: kirkwood: remove legacy clk alias for mv643xx_eth
With all boards converted to DT enabled mv643xx_eth we can now remove the clock alias for gbe clocks. The workaround for ge0/ge1 clock gates is not removed, as Kirkwood ethernet controllers loose MAC address stored in internal registers on gated ge0/ge1 clocks. Signed-off-by: Sebastian Hesselbarth --- Note: I confirm that the above workaround is still required, i.e. when booting DT kernel with non-DT boot loader (no local-mac-address property) MAC address registers looses its content on clock gating. Cc: David Miller Cc: Lennert Buytenhek Cc: Jason Cooper Cc: Andrew Lunn Cc: Benjamin Herrenschmidt Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/mach-kirkwood/board-dt.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c index e9647b8..8db388a 100644 --- a/arch/arm/mach-kirkwood/board-dt.c +++ b/arch/arm/mach-kirkwood/board-dt.c @@ -66,12 +66,10 @@ static void __init kirkwood_legacy_clk_init(void) */ clkspec.args[0] = CGC_BIT_GE0; clk = of_clk_get_from_provider(&clkspec); - orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk); clk_prepare_enable(clk); clkspec.args[0] = CGC_BIT_GE1; clk = of_clk_get_from_provider(&clkspec); - orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk); clk_prepare_enable(clk); } -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
With DT support for mv643xx_eth, board specific init for some boards now is unneccessary. Remove those board files, Kconfig entries, and corresponding entries in kirkwood_defconfig. Signed-off-by: Sebastian Hesselbarth --- Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed the lock-up is not caused by accessing clock gating registers but rather non-existent device registers. This will be addressed by dtsi separation for kirkwood and bobcat SoC variants. Changelog: v3->v4: - remove more boards that don't require board specific setup Cc: David Miller Cc: Lennert Buytenhek Cc: Jason Cooper Cc: Andrew Lunn Cc: Benjamin Herrenschmidt Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/configs/kirkwood_defconfig | 16 arch/arm/mach-kirkwood/Kconfig| 117 - arch/arm/mach-kirkwood/Makefile | 16 arch/arm/mach-kirkwood/board-dnskw.c |7 -- arch/arm/mach-kirkwood/board-dockstar.c | 32 --- arch/arm/mach-kirkwood/board-dreamplug.c | 35 arch/arm/mach-kirkwood/board-dt.c | 38 arch/arm/mach-kirkwood/board-goflexnet.c | 34 --- arch/arm/mach-kirkwood/board-guruplug.c | 33 --- arch/arm/mach-kirkwood/board-ib62x0.c | 29 -- arch/arm/mach-kirkwood/board-iconnect.c | 10 --- arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 34 --- arch/arm/mach-kirkwood/board-km_kirkwood.c| 44 -- arch/arm/mach-kirkwood/board-lsxl.c | 16 arch/arm/mach-kirkwood/board-mplcec4.c| 14 --- arch/arm/mach-kirkwood/board-ns2.c| 35 arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 -- arch/arm/mach-kirkwood/board-readynas.c |6 -- arch/arm/mach-kirkwood/board-ts219.c | 13 --- arch/arm/mach-kirkwood/board-usi_topkick.c| 29 -- 20 files changed, 584 deletions(-) delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig index a1d8252..540ca51 100644 --- a/arch/arm/configs/kirkwood_defconfig +++ b/arch/arm/configs/kirkwood_defconfig @@ -30,27 +30,11 @@ CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_T5325=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y -CONFIG_MACH_CLOUDBOX_DT=y CONFIG_MACH_DLINK_KIRKWOOD_DT=y -CONFIG_MACH_DOCKSTAR_DT=y -CONFIG_MACH_DREAMPLUG_DT=y -CONFIG_MACH_GOFLEXNET_DT=y -CONFIG_MACH_GURUPLUG_DT=y -CONFIG_MACH_IB62X0_DT=y -CONFIG_MACH_ICONNECT_DT=y -CONFIG_MACH_INETSPACE_V2_DT=y -CONFIG_MACH_IOMEGA_IX2_200_DT=y -CONFIG_MACH_KM_KIRKWOOD_DT=y CONFIG_MACH_LSXL_DT=y CONFIG_MACH_MPLCEC4_DT=y -CONFIG_MACH_NETSPACE_LITE_V2_DT=y -CONFIG_MACH_NETSPACE_MAX_V2_DT=y -CONFIG_MACH_NETSPACE_MINI_V2_DT=y -CONFIG_MACH_NETSPACE_V2_DT=y CONFIG_MACH_NSA310_DT=y -CONFIG_MACH_OPENBLOCKS_A6_DT=y CONFIG_MACH_READYNAS_DT=y -CONFIG_MACH_TOPKICK_DT=y CONFIG_MACH_TS219_DT=y # CONFIG_CPU_FEROCEON_OLD_ID is not set CONFIG_PREEMPT=y diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index 7509a89..c2fd30b 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -146,13 +146,6 @@ config ARCH_KIRKWOOD_DT Say 'Y' here if you want your kernel to support the Marvell Kirkwood using flattened device tree. -config MACH_CLOUDBOX_DT - bool "LaCie CloudBox NAS (Flattened Device Tree)" - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the LaCie - CloudBox NAS, using Flattened Device Tree. - config MACH_DLINK_KIRKWOOD_DT bool "D-Link Kirkwood-based NAS (Flattened Device Tree)" select ARCH_KIRKWOOD_DT @@ -161,69 +154,6 @@ config MACH_DLINK_KIRKWOOD_DT Kirkwood-based D-Link NASes such as DNS-320 & DNS-325, using Flattened Device Tree. -config MACH_DOCKSTAR_DT - bool "Seagate FreeAgent Dockstar (Flattened Device Tree)" - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the - Seagate FreeAgent Dockstar (Flattened Device Tree). - -config MACH_DREAMPLUG_DT - bool "Marvell DreamPlug (Flattened Device Tree)&quo
[PATCH v4 12/12] ARM: orion5x: remove legacy mv643xx_eth board setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards. This patch removes eth setup
for all orion5x DT board files.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-orion5x/edmini_v2-setup.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c
b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..d9de926 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -96,14 +95,6 @@ static struct platform_device edmini_v2_nor_flash = {
};
/*
- * Ethernet
- /
-
-static struct mv643xx_eth_platform_data edmini_v2_eth_data = {
- .phy_addr = 8,
-};
-
-/*
* RTC 5C372a on I2C bus
/
@@ -152,7 +143,6 @@ void __init edmini_v2_init(void)
* Configure peripherals.
*/
orion5x_ehci0_init();
- orion5x_eth_init(&edmini_v2_eth_data);
mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
EDMINI_V2_NOR_BOOT_SIZE);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/21/2013 07:48 PM, Andrew Lunn wrote:
On Tue, May 21, 2013 at 06:41:44PM +0200, Sebastian Hesselbarth wrote:
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.
Signed-off-by: Sebastian Hesselbarth
---
...
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg =<0>;
+ interrupts =<29>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
Hi Sebastian
Its probably a good idea to set the local administration bit in this
MAC address. i.e. first byte is 02.
Andrew,
we just need an invalid address here to trigger the default behavior of
the driver and load the MAC address from its register. As PPC binding
documentation also has all zero, I just took it.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 12:04 PM, tiejun.chen wrote:
On 05/22/2013 05:43 PM, Sebastian Hesselbarth wrote:
On 05/21/2013 07:48 PM, Andrew Lunn wrote:
On Tue, May 21, 2013 at 06:41:44PM +0200, Sebastian Hesselbarth wrote:
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a
default
phy node is also added with a note to set its reg property on a
per-board
basis.
Signed-off-by: Sebastian Hesselbarth
---
...
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg =<0>;
+ interrupts =<29>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
Hi Sebastian
Its probably a good idea to set the local administration bit in this
MAC address. i.e. first byte is 02.
Andrew,
we just need an invalid address here to trigger the default behavior of
the driver and load the MAC address from its register. As PPC binding
documentation also has all zero, I just took it.
The truth is in PPC case, often we set the real mac address with some
variables like 'eth[x]addr' in u-boot prompt, then u-boot will parse
that value to fill the dtb. At last the associated driver can get the
actual mac address from the dtb. And especially for those older u-boot
version, even you have to reset the 'local-mac-address' property in dts
directly with the real mac address before generate the dtb since the
older u-boot have no this ability to fill dtb again before pass the kernel.
Tiejun,
with Marvell SoCs it is no different, except that there is almost no dtb
support in their u-boot. The default behavior of the driver always was
to load the MAC address from its register if there is no valid overwrite
value. Using an invalid address (and all zero above is invalid) will
cause of_get_mac_address() to fail (which we allow), the corresponding
platform_data will never be written, and cause the default behavior.
We only need an invalid address passed initially on local-mac-address.
DT aware boot loader will overwrite but DT agnositic boot loader will
not. I can put any invalid MAC address in here, so I have chosen the
very first I can think of.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 06:59 PM, Jason Gunthorpe wrote: On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote: iirc, our solution to this was to parse the ATAGs for the mac addr and update the appended dtb. This way, module load and unload would work without loosing the mac address. I believe Jason Gunthorpe has a patch to atags_to_fdt() for this... This should allow us to get rid of the clocks hack. Sorry, no, we don't use ATAGs here, our platforms start the kernel with a correct DTB that has the correct mac address to use. My patch was to have the driver accept it, and I think Sebastian has already got that functionality... Not neccessary anyway, after talking Jason C in a Kirkwood-only workaround I prepared a patch that reads mac address registers early and stores it in the local-mac-address property. Just tested on Dockstar with gated clocks and modular DT mv643xx_eth. Will append to the DT mv643xx_eth patch set if a v5 will be required or as single patch prior Jason C taking in the ARM part of it otherwise. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 07:35 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote: On 05/22/2013 06:59 PM, Jason Gunthorpe wrote: On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote: iirc, our solution to this was to parse the ATAGs for the mac addr and update the appended dtb. This way, module load and unload would work without loosing the mac address. I believe Jason Gunthorpe has a patch to atags_to_fdt() for this... This should allow us to get rid of the clocks hack. Sorry, no, we don't use ATAGs here, our platforms start the kernel with a correct DTB that has the correct mac address to use. My patch was to have the driver accept it, and I think Sebastian has already got that functionality... Not neccessary anyway, after talking Jason C in a Kirkwood-only workaround I prepared a patch that reads mac address registers early and stores it in the local-mac-address property. Sweet! Just tested on Dockstar with gated clocks and modular DT mv643xx_eth. Will append to the DT mv643xx_eth patch set if a v5 will be required or as single patch prior Jason C taking in the ARM part of it otherwise. Please post, in-reply-to v4 is fine. Hmm, maybe a little bit too early. While restoring the MAC address now works, another bug arises which I guess is related with phy setup and aneg. Will investigate and update patch set accordingly. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 07:48 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote: Hmm, maybe a little bit too early. While restoring the MAC address now works, another bug arises which I guess is related with phy setup and aneg. Will investigate and update patch set accordingly. Cool, chances are, we should be able to take that patch in by itself for this merge window... Which patch do you mean? The local-mac-address workaround will only be available for DT mv643xx_eth because it uses the DT node to store the MAC. Anyway, I found the bit that caused the other issue. It is the Clk125_Bypass_En bit in PORT_SERIAL_CONTROL1 register. What bothers me about it is: - Only Dove and Kirkwood have the bit, MV78x00 doesn't have it, Orion5x doesn't have the register at all. With ppc mv64x60 I can only guess, but think it is like in Orion5x. - Reset value of that bit should be 0, but after gating clock on Kirkwood it is set to 1 causing wrong port clock to be selected. Also Thomas Petazzoni confirmed that it is set after reset so either FS is wrong about it or BootROM messes with it. - Kirkwood and Dove FS tell me that port link must be down when you change the bit. As I can't be sure about how mv643xx_eth will behave on other platforms except Kirkwood and Dove when writing that register, I tend to force that bit to zero in the driver but only for those two by #ifdefs. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 08:24 PM, Jason Gunthorpe wrote: On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote: Not neccessary anyway, after talking Jason C in a Kirkwood-only workaround I prepared a patch that reads mac address registers early and stores it in the local-mac-address property. That sounds great, but, FWIW, our bootloaders don't set the MAC address registers. Does the work around only trigger if the local-mac-address property is 0? I already thought about bootloaders not setting the register, but I will not start parsing 1001 places for a valid MAC only for those. Also reading the MAC address registers is default behavior of mv643xx_eth if no MAC address is passed through platform_data. But you are right, there is plenty of sanity checks in the workaround to ensure that local-mac-address is only overwritten by it when - you are on DT - there is no valid MAC address in that node (of_get_mac_address) - there is a local-mac-address property with a length of 6 bytes So this workaround only applies on DT booted kernels with no mac set in DT. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 08:49 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote: On 05/22/2013 07:48 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote: Hmm, maybe a little bit too early. While restoring the MAC address now works, another bug arises which I guess is related with phy setup and aneg. Will investigate and update patch set accordingly. Cool, chances are, we should be able to take that patch in by itself for this merge window... Which patch do you mean? The local-mac-address workaround will only be available for DT mv643xx_eth because it uses the DT node to store the MAC. I thought you were replacing the unconditional ethernet clock grabbing with reading the mac from the registers and updating the dtb? In mach-kirkwood/board-dt.c? True. But there is no node for ethernet controllers in kirkwood.dtsi yet. It will be there with mv643xx_eth DT patches applied and that is when the corresponding replacement patch should also be taken in. I was just confused about your referral to the merge window, because I guess it is up to David Miller to decide when/whether to take mv643xx_eth patches in. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On 05/22/2013 07:48 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote: On 05/22/2013 07:35 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote: Just tested on Dockstar with gated clocks and modular DT mv643xx_eth. Will append to the DT mv643xx_eth patch set if a v5 will be required or as single patch prior Jason C taking in the ARM part of it otherwise. Please post, in-reply-to v4 is fine. Hmm, maybe a little bit too early. While restoring the MAC address now works, another bug arises which I guess is related with phy setup and aneg. Will investigate and update patch set accordingly. Ok, have it working now by properly clearing CLK125_BYPASS_EN bit in PORT_SERIAL_CTRL1 register for Kirkwood only. I have two more patches ready that I will post as single patches in reply to v4. If David gives his ACK for the patch set and names a branch to base it on, I will send a v5 including all patches. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
Kirkwood ethernet controllers suffer from loosing MAC register content
on gated clocks. In the past this was prevented by not gating the ethernet
controller clocks. With DT support for mv643xx_eth and corresponding
nodes available, a different approach is more reasonable.
This patch replaces the former clock gating workaround by parsing the
ethernet controller nodes for *invalid* MAC addresses and overwrites
the local-mac-address property with MAC register contents early. The
clock can now properly gated in modular mv643xx_eth and DT agnostic
boot loader scenarios because mv643xx_eth will find the stored MAC
in the corresponding MAC address property.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-kirkwood/board-dt.c | 67 +
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-dt.c
b/arch/arm/mach-kirkwood/board-dt.c
index a86b41c..0aad9f7 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -31,6 +33,56 @@ static struct of_device_id kirkwood_dt_match_table[]
__initdata = {
};
/*
+ * Kirkwood ethernet controllers suffer from loosing the MAC address
+ * register content on gated clocks. Rather than always ungate the
+ * clocks, we get the MAC address early and put it into DT for those
+ * boot loaders that don't provide a valid MAC address property.
+ */
+#define ETH_MAC_ADDR_L(n) (0x400 + ((n) * 0x400) + 0x14)
+#define ETH_MAC_ADDR_H(n) (0x400 + ((n) * 0x400) + 0x18)
+
+static void __init kirkwood_dt_eth_quirk(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "marvell,orion-eth") {
+ struct device_node *pnp;
+ void __iomem *base;
+
+ if (!of_device_is_available(np))
+ continue;
+
+ base = of_iomap(np, 0);
+ if (!base)
+ continue;
+
+ for_each_available_child_of_node(np, pnp) {
+ const void *mac_addr;
+ struct property *p;
+ u32 n, reg[2];
+
+ mac_addr = of_get_mac_address(pnp);
+ if (mac_addr)
+ continue;
+
+ p = of_find_property(pnp, "local-mac-address", NULL);
+ if (!p || p->length != 6)
+ continue;
+
+ if (of_property_read_u32(pnp, "reg", &n))
+ continue;
+
+ reg[0] = cpu_to_be32(readl(base + ETH_MAC_ADDR_H(n)));
+ reg[1] = cpu_to_be32(readl(base +
+ ETH_MAC_ADDR_L(n)) << 16);
+ memcpy((void *)p->value, reg, 6);
+ }
+
+ iounmap(base);
+ }
+}
+
+/*
* There are still devices that doesn't know about DT yet. Get clock
* gates here and add a clock lookup alias, so that old platform
* devices still work.
@@ -42,7 +94,6 @@ static void __init kirkwood_legacy_clk_init(void)
struct device_node *np = of_find_compatible_node(
NULL, NULL, "marvell,kirkwood-gating-clock");
struct of_phandle_args clkspec;
- struct clk *clk;
clkspec.np = np;
clkspec.args_count = 1;
@@ -58,19 +109,6 @@ static void __init kirkwood_legacy_clk_init(void)
clkspec.args[0] = CGC_BIT_SDIO;
orion_clkdev_add(NULL, "mvsdio",
of_clk_get_from_provider(&clkspec));
-
- /*
-* The ethernet interfaces forget the MAC address assigned by
-* u-boot if the clocks are turned off. Until proper DT support
-* is available we always enable them for now.
-*/
- clkspec.args[0] = CGC_BIT_GE0;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
-
- clkspec.args[0] = CGC_BIT_GE1;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
}
static void __init kirkwood_of_clk_init(void)
@@ -97,6 +135,7 @@ static void __init kirkwood_dt_init(void)
/* Setup root of clk tree */
kirkwood_of_clk_init();
+ kirkwood_dt_eth_quirk();
kirkwood_cpuidle_init();
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
MAC address register contents on clock gating but also some important
registers are reset to values that would break ethernet. This patch
clears the CLK125_BYPASS_EN bit for DT enabled Kirkwood only by using
of_machine_is_compatible() instead of #ifdefs. Non-DT Kirkwood is not
affected as it installs a clock gating workaround because of the MAC
address issue above. Other Orion SoCs do not suffer from register reset,
do not have the bit in question, or do not have the register at all.
Moreover, system controllers on PPC using this driver should also be
protected from clearing that bit.
Signed-off-by: Sebastian Hesselbarth
---
Note: In contrast to the reset value of 0 for CLK125_BYPASS_EN bit as
stated in Kirkwood datasheet, we confirmed that reset value is 1 instead.
Either datasheet is wrong about it, there is some post-boot self-check or
BootROM flips that bit.
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index f2c229c..d9ad8c7 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -119,6 +119,8 @@ static char mv643xx_eth_driver_version[] = "1.4";
#define LINK_UP 0x0002
#define TXQ_COMMAND0x0048
#define TXQ_FIX_PRIO_CONF 0x004c
+#define PORT_SERIAL_CONTROL1 0x004c
+#define CLK125_BYPASS_EN 0x0010
#define TX_BW_RATE 0x0050
#define TX_BW_MTU 0x0058
#define TX_BW_BURST0x005c
@@ -2843,6 +2845,14 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
mp->dev = dev;
+ /* Kirkwood resets some registers on gated clocks. Especially
+* CLK125_BYPASS_EN must be cleared but is not available on
+* all other SoCs/System Controllers using this driver.
+*/
+ if (of_machine_is_compatible("marvell,kirkwood"))
+ wrlp(mp, PORT_SERIAL_CONTROL1,
+rdlp(mp, PORT_SERIAL_CONTROL1) & ~CLK125_BYPASS_EN);
+
/*
* Start with a default rate, and if there is a clock, allow
* it to override the default.
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
On 05/22/2013 10:36 PM, Simon Baatz wrote:
Hi Sebastian,
On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
With DT support for mv643xx_eth, board specific init for some boards now
is unneccessary. Remove those board files, Kconfig entries, and
corresponding entries in kirkwood_defconfig.
Signed-off-by: Sebastian Hesselbarth
---
Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
the lock-up is not caused by accessing clock gating registers but rather
non-existent device registers. This will be addressed by dtsi separation
for kirkwood and bobcat SoC variants.
Changelog:
v3->v4:
- remove more boards that don't require board specific setup
...
We still have:
static const char * const kirkwood_dt_board_compat[] = {
"globalscale,dreamplug",
"globalscale,guruplug",
"dlink,dns-320",
"dlink,dns-325",
"iom,iconnect",
"raidsonic,ib-nas62x0",
"qnap,ts219",
"seagate,dockstar",
"seagate,goflexnet",
"buffalo,lsxl",
"iom,ix2-200",
"keymile,km_kirkwood",
"lacie,cloudbox",
"lacie,inetspace_v2",
"lacie,netspace_lite_v2",
"lacie,netspace_max_v2",
"lacie,netspace_mini_v2",
"lacie,netspace_v2",
"mpl,cec4",
"netgear,readynas-duo-v2",
"plathome,openblocks-a6",
"usi,topkick",
"zyxel,nsa310",
NULL
};
in that file. I think it does not make sense that we need to list
boards here that can be described fully by DT. When adding such a
board in the future, you will still need to adapt board-dt.c.
True, will remove the redundant compatible strings for v5.
Actually, if I am not missing something, all compatible strings except
"marvell,kirkwood" are redundant as long as board.dts append it
correctly.
Should we remove the boards that you removed above here as well and
add
"marvell,kirkwood-88f6192",
"marvell,kirkwood-88f6281",
"marvell,kirkwood-88f6282",
"marvell,kirkwood-88f6283",
"marvell,kirkwood-88f6702",
"marvell,kirkwood-98DX4122",
or even just state "marvell,kirkwood"?
I would stick with "marvell,kirkwood" only. This is SoC init code and
we do not distinguish variants here at all.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
On 05/22/2013 10:16 PM, Jason Gunthorpe wrote:
On Wed, May 22, 2013 at 10:04:02PM +0200, Sebastian Hesselbarth wrote:
Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
MAC address register contents on clock gating but also some important
registers are reset to values that would break ethernet. This patch
FWIW, we found that the bootloader has to write to PSC1, the driver
doesn't work with the power on/reset value of the register. So I think
it is safe to assume that all kirkwood bootloaders alter the value.
It is safe to assume the bootloader alters it, but that modification is
lost when clocks get gated. I assume on clock ungate, the controller is
reset. Saying this, I will double check Dove's reset value but looks
like reset mess has been fixed in that later SoC.
Our systems write the value 0x00638488 to PSC1.
I looked at patching mv643xx_eth, but ran into the same complexity you
did, it isn't clear what variants of this IP block have the
register/etc.
For Orion SoCs it is quite clear to me, with Gregory Clement and Thomas
Petazzoni we could also confirm if it does any harm there if we
unconditionally clear it. But for PPC system controllers I have no
idea...
+ /* Kirkwood resets some registers on gated clocks. Especially
+* CLK125_BYPASS_EN must be cleared but is not available on
+* all other SoCs/System Controllers using this driver.
+*/
+ if (of_machine_is_compatible("marvell,kirkwood"))
+ wrlp(mp, PORT_SERIAL_CONTROL1,
+rdlp(mp, PORT_SERIAL_CONTROL1)& ~CLK125_BYPASS_EN);
of_machine_is_compatible seems heavy handed, I would expect this to be
based on the compatible string of the ethernet node itself, not the
machine??
I have no strong opinion about checking the machine compatible or have
an extra compatible string for Kirkwood ethernet. Both would work fine
and are checked once upon probe anyway.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
On 05/22/2013 11:02 PM, Jason Cooper wrote: On Wed, May 22, 2013 at 10:55:43PM +0200, Sebastian Hesselbarth wrote: On 05/22/2013 10:36 PM, Simon Baatz wrote: Hi Sebastian, On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote: With DT support for mv643xx_eth, board specific init for some boards now is unneccessary. Remove those board files, Kconfig entries, and corresponding entries in kirkwood_defconfig. Signed-off-by: Sebastian Hesselbarth --- Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed the lock-up is not caused by accessing clock gating registers but rather non-existent device registers. This will be addressed by dtsi separation for kirkwood and bobcat SoC variants. Changelog: v3->v4: - remove more boards that don't require board specific setup ... I would stick with "marvell,kirkwood" only. This is SoC init code and we do not distinguish variants here at all. Agreed, nice catch Simon. I just confirmed all kirkwood dts/dtsi properly set "marvell,kirkwood" in their compatible strings. Will remove all other comapatible strings from mach-kirkwood/board-dt.c as Simon suggested for v5. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
On 05/23/2013 08:40 PM, Jason Cooper wrote: On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote: On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote: Shouldn't it rather be compatible = "marvell,kirkwood-eth", "marvell,orion-eth"; Not sure about orion-eth? Jason, Jason, sorry I didn't came back to this conversation earlier. I already reworked the patch to rely on of_device_is_compatible(.."marvell,kirkwood-eth"..). This is a kirkwood only thing as other Orions cannot do clock gating or retain critcal register content (Dove). I will stick with orion-eth for all other and maybe introduce new compatible strings (and new fixes) as soon as issues surface. I'm inclined to go with of_machine_is_compatible() since the only concrete difference we know is that the tweak is needed on kirkwood and nowhere else. But there is a larger problem here then just this one bit. The PSC1 register must be set properly for the board layout, and today we rely on the bootloader to set it. In fact, even with Sebastian's change the ethernet port won't work without bootloader intervention. The PortReset bit should also be cleared by the driver (and it is only present on some variants of this IP block, apparently). Actually, fixing modular scenarios is only for the sake of multiarch someday. I don't see the point in running current kernel without eth compiled in _on a NAS SoC_ ;) On Dockstar which I tested, clearing CLK125_BYPASS_EN to make it work after clock gating, it might be a coincidence that bootloader's PSC1 setup matches reset value here - so please test the patch on other Kirkwood boards also. But, as long as no other issue arise, I will not start to modifiy mv643xx_eth out of the blue. I has been working for ages and breaking PPC is not my intention. There are other things David Miller already requested to get fixed and honestly I even thought about a fresh start for it. Maybe I'll come back to it when barebox gets it's driver someday. We know that some Marvell SOC's wack the ethernet registers when they clock gate, and the flip of Clk125Bypass is another symptom of this general problem. Which SoCs except Kirkwood? I cannot reproduce any of this behavior on Dove - and from what I can see from the FS of Orion5x or MV78x00 there are no clock gating registers. So, long term, the PSC1 must be fully set by the driver, based on DT information describing the board (eg RGMII/MII/1000Base-X [SFP] Phy type), and the layout of this register seems to vary on a SOC by SOC basis. Agree, but I tend to not go at it now. mv643xx_eth has never set up that registers and actually it never connects anything else than GMII phy (or no phy at all). The latter is easy but the for the other, I like to give up that brain-dead multi-device driver and stick with one device for both shared and up to three ports. From what I can see from e.g. ixgbe or any other multi-port eth drivers they all attach the network device to a single (pci) device. Thus, I think it is appropriate to call this variant of the eth IP 'marvell,kirkwood-eth' which indicates that the register block follows the kirkwood manual and the PSC1 register specifically has the kirkwood layout. Ok, so mv643xx_eth would match both "marvell,orion-eth" and "marvell,kirkwood-eth", then write to PSC1 iff it sees a node matching "marvell,kirkwood-eth". I'm not too keen on that, however, the matching of the machine doesn't look to good, either. I didn't choose "marvell,mv643xx-eth" for two reasons (a) The DT layout is slightly different with phy-handle instead of phy and marvell prefixed properties. Choosing a compatible string that matches any PPC compatible string will cause driver racing with sysdev code to set up platform_data. (b) I chose to name the controller "orion-eth" and the port "orion-eth-port" .. PPC has "mv64360-eth" for the port and some "mv64360-eth-block" or "-group" for the controller. IMHO not intuitive, but it just a name anyway. Perhaps a better answer is to add a boolean, "marvell,kirkwood_psc1" and check for that? Or, marvell,psc1_reset =<0xWWXXYYZZ>; For the _long_ run: Exploit either already present phy properties for MII and friends or introduce new marvell prefixed .. but not misuse DT for register values here. Each SoC should setup mv643xx_eth properly, but that should be based on a clean approach _and_ enough people willing to test that. I just have a Dockstar and Topkick which is running 24/7. I didn't even check if only 6281 suffers from it or also 6282 or maybe only some revisions of 6281. This patch is a fix, nothing more nothing less. If you have Kirkwoods around, please test if it suffers from loosing the MAC address and if it works after insmod with the fix installed. The question is what other Marvell SOCs have the same PSC1 layout as kirkwood? I think marvell,psc1_reset =<>; gives us the most flexibility in accurately describing the hardware. IMHO using that is just another workar
Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
On 05/24/2013 07:13 PM, Russell King - ARM Linux wrote: Do you really want that on ARM? Given the fiasco with the location of the registers, are you sure you want to place more trust in that direction? Does it give you a warm fuzzy feeling to know that you might have to work out some way to patch vendor supplied bytecode? Don't get me wrong. I want mv643xx_eth DT or even platform_data to evolve to a fully self configured driver not depending on proper u-boot setup at all. But I don't want to go that road now and I wonder if it might be safer for us (and PPC guys) if we start mv643xx_eth over from scratch one day. For this patch set, I want a basic DT binding that works. Patching the driver to play with kirkwood loosing the MAC and other important registers is not my main concern here. If clearing that one bit doesn't help for all kirkwood boards, I'd rather leave the non-gating workaround. mv643xx_eth not knowing DT for ARM is stalling last important bits for Orion SoCs. I want this to go in first as with David another maintainer is involved. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
On 05/26/2013 06:04 AM, David Miller wrote: From: Sebastian Hesselbarth Date: Wed, 22 May 2013 22:04:01 +0200 + memcpy((void *)p->value, reg, 6); This cast is completely unnecessary, non-void to void pointer casts are automatic. If it is necessary, because p->value is const, then you are trying to change something behind the OF layer's back and need to use the appropriate interface to change the property contents. David, good you mention it. I added Grant on Cc and will give a short sum-up why I casted the const from property->value away here. Maybe I overlooked the API for modifying the DT property but as far as I've seen - there is no API for modifying it. And yes, you are right, it is kind of an abuse of DT here. As Kirkwoods loose their MAC address on clock gating, I was looking for a place to store it early. (a) DT property "local-mac-address" looked as a good place as it will allow the driver to find it without any extra code. Of course, I am doing severaly sanity checks if it is safe to overwrite it, i.e. no other MAC set, property is there, long enough. If Grant also NACKs modifying the DT we basically have two more options left for Kirkwood: (b) have MAC stored early in two global arrays in board init and reference that from mv643xx_eth or (c) leave the clock ungated unconditionally on all Kirkwoods. I can live with all three, just name it and I prepare a final patch set. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
On 05/27/13 11:39, Benjamin Herrenschmidt wrote: On Mon, 2013-05-27 at 02:23 -0700, David Miller wrote: Sparc has an of_set_property(), it needs to become generic. There is an of_update_property(), we could change the name though, yours is nicer :-) Ben, David, I had a quick look at sparc's of_set_property. Nothing special except it depends on OF_DYNAMIC at some place. Using of_update_property instead should be the correct function to use. Thanks for the hint, I'll update the patches accordingly and send v5 hopefully by today. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
On 05/27/2013 11:50 PM, Benjamin Herrenschmidt wrote: On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote: On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote: However, that wouldn't help much with the allocation/leak problem, though at least it would be easier to use. It could also *try* to re-use the current allocation if the new content is of smaller or equal size. I thought that dtc tried to aggressively save space by folding identical strings. If you tried to reuse a property that had its contents shared with another one, you would get interesting results I guess. It used to be only property names, unless that has changed in recent dtc. But that's a good point, we probably want a flag in struct property like we have for nodes, indicating whether it comes from the original fdt data pool or not. But isn't that what current sparc implementation of of_set_property does when it marks the property as dynamic? Anyway, this definitely exceeds my knowledge of OF API for sure, so what do I do about the MAC workaround now? Prepare the patch with global arrays and switch to some of_set_property as soon as it is available? Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 01/13] net: mv643xx_eth: use phy_disconnect instead of phy_detach
Using a separated mdio bus driver with mvmdio, phy_detach on network device
removal will not stop the phy and finally lead to NULL pointer dereference
in mvmdio due to non-existent network device. Use phy_disconnect instead
to properly stop phy device from accessing network device prior removal of
the network device.
Signed-off-by: Sebastian Hesselbarth
---
Note: I observed this behavior when removing a modular mv643xx_eth driver
after attaching it to a phy handled by (also modular) mvmdio. The mvmdio
conversion has been done in
commit c3a07134e6aa5b93a37f72ffa3d11fadf72bf757
("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
and should go back any -stable version with that commit (propably only 3.9)
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2ad1494..2480a2f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2805,7 +2805,7 @@ static int mv643xx_eth_remove(struct platform_device
*pdev)
unregister_netdev(mp->dev);
if (mp->phy != NULL)
- phy_detach(mp->phy);
+ phy_disconnect(mp->phy);
cancel_work_sync(&mp->tx_timeout_task);
if (!IS_ERR(mp->clk))
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 03/13] net: mv643xx_eth: add phy_node to platform_data struct
This adds a struct device_node pointer for a phy passed by phandle
to mv643xx_eth node.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
include/linux/mv643xx_eth.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 141d395..6e8215b 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -30,6 +30,7 @@ struct mv643xx_eth_shared_platform_data {
#define MV643XX_ETH_PHY_ADDR(x)(0x80 | (x))
#define MV643XX_ETH_PHY_NONE 0xff
+struct device_node;
struct mv643xx_eth_platform_data {
/*
* Pointer back to our parent instance, and our port number.
@@ -41,6 +42,7 @@ struct mv643xx_eth_platform_data {
* Whether a PHY is present, and if yes, at which address.
*/
int phy_addr;
+ struct device_node *phy_node;
/*
* Use this MAC address if it is valid, overriding the
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 02/13] net: mv643xx_eth: use managed devm_ioremap for port registers
Make use of managed devm_ioremap and remove corresponding iounmap.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2480a2f..19964e9 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2470,7 +2470,7 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (msp == NULL)
return -ENOMEM;
- msp->base = ioremap(res->start, resource_size(res));
+ msp->base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
if (msp->base == NULL)
return -ENOMEM;
@@ -2498,7 +2498,6 @@ static int mv643xx_eth_shared_remove(struct
platform_device *pdev)
{
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
- iounmap(msp->base);
if (!IS_ERR(msp->clk))
clk_disable_unprepare(msp->clk);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 04/13] net: mv643xx_eth: use of_phy_connect if phy_node present
This connects to a phy node passed to the port device instead of probing
the phy by phy_addr.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 19964e9..fa8c84a 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
static char mv643xx_eth_driver_name[] = "mv643xx_eth";
static char mv643xx_eth_driver_version[] = "1.4";
@@ -2715,17 +2716,27 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
netif_set_real_num_tx_queues(dev, mp->txq_count);
netif_set_real_num_rx_queues(dev, mp->rxq_count);
- if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
+ err = 0;
+ if (pd->phy_node) {
+ mp->phy = of_phy_connect(mp->dev, pd->phy_node,
+mv643xx_eth_adjust_link, 0,
+PHY_INTERFACE_MODE_GMII);
+ if (!mp->phy)
+ err = -ENODEV;
+ } else if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
mp->phy = phy_scan(mp, pd->phy_addr);
- if (IS_ERR(mp->phy)) {
+ if (IS_ERR(mp->phy))
err = PTR_ERR(mp->phy);
- if (err == -ENODEV)
- err = -EPROBE_DEFER;
- goto out;
- }
- phy_init(mp, pd->speed, pd->duplex);
+ else
+ phy_init(mp, pd->speed, pd->duplex);
}
+ if (err == -ENODEV) {
+ err = -EPROBE_DEFER;
+ goto out;
+ }
+ if (err)
+ goto out;
SET_ETHTOOL_OPS(dev, &mv643xx_eth_ethtool_ops);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 00/13] net: mv643xx_eth DT support and fixes
This patch set picks up work by Florian Fainelli bringing full DT
support to mv643xx_eth and Marvell SoCs using it.
The current v5 patch set drops 1:1 compatibiliy with PPC binding
for two reasons:
(a) PPC parses DT nodes in arch/ppc/sysdev and creates non-DT
platform_devices itself,
(b) property and node naming for new ethernet devices is slightly
different ("phy" vs "phy-handle", "marvell," prefix)
Anyway, the two bindings are functionally compatible and PPC bindings
can be converted if desireable. The patch set if fully bisectable and
care has been taken to (a) not reparse on PPC platforms, (b) allow to
use platform_device based registration even if on CONFIG_OF. Not tested
is double registration issues, i.e. if DT nodes are provided but legacy
registration it not yet removed. This double registration should lead
to either non-DT or DT registered device fail on already claimed
ressources.
Also this patch set picks up the opportunity to fix some repeatedly
reported issues with modular mvmdio/mv643xx_eth loading, unloading,
and reloading. It has been tested on SolidRun CuBox (Dove) and
Seagate Dockstar, QNAP, and USI Topkick (Kirkwood) by me or Andrew
Lunn.
Patch 1 fixes an issue introduced with switch to separate mvmdio
driver, where detaching mv643xx_eth from a phy will not stop the
phy state machine and finally dereference the already removed network
device. Using phy_disconnect properly stops the phy state machine
before detaching from it. Perhaps, this patch should go back in
stable (most likely 3.9 only) if mvmdio separation patch went in
there.
Patch 2 makes use of managed devm_ioremap for the last remaining
non-managed resource.
Patches 3-4 prepare DT support for mv643xx_eth by adding a phy_node
pointer to platform_data and exploiting that phy_node when attaching
to a phy.
Patch 5 adds a Kirkwood specific workaround for PORT_SERIAL_CTRL1
register which is reset to loopback mode when clocks are gated.
Patch 6 introduces DT parsing support for mv643xx_eth by adding a
match table for marvell,orion-eth and marvell,kirkwood-eth to the
shared driver and adding a platform_device for each of its child
nodes.
Patches 7-9 add corresponding device tree nodes to Marvell Dove,
Kirkwood, and Orion5x including all boards. Where known, also
the PHY compatible string has been set to what is reported in the
boards boot loader.
Patches 10, 11-12, and 14 finally remove all legacy platform_device
based registration from Dove, Kirkwood, and Orion5x DT setup. For
Kirkwood also now obsolete board specific setup is removed from
common DT board setup, Kconfig, Makefile, and kirkwood_defconfig.
For the patches above I suggest to take Patches 1-6 through David
Miller's branch, and Patches 7-12 through Jason Cooper's when the
former have appeared on mainline linux. The patch set has been based
on v3.10-rc3.
Overall Changelog:
v4->v5: v5 drops Kirkwood MAC address workaround by using DT
property because OF API does not allow to modify properties
easily. Instead the current workaround by not gating ge clocks
is kept. The OF property workaround is postponed until some
easy to use of_set_property is available.
Sebastian Hesselbarth (13):
net: mv643xx_eth: use phy_disconnect instead of phy_detach
net: mv643xx_eth: use managed devm_ioremap for port registers
net: mv643xx_eth: add phy_node to platform_data struct
net: mv643xx_eth: use of_phy_connect if phy_node present
net: mv643xx_eth: proper initialization for Kirkwood SoCs
net: mv643xx_eth: add DT parsing support
ARM: dove: add gigabit ethernet and mvmdio device tree nodes
ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
ARM: dove: remove legacy mv643xx_eth setup
ARM: kirkwood: remove legacy clk alias for mv643xx_eth
ARM: kirkwood: remove redundant DT board files
ARM: orion5x: remove legacy mv643xx_eth board setup
.../devicetree/bindings/net/marvell-orion-net.txt | 85 +
arch/arm/boot/dts/dove-cubox.dts |7 +
arch/arm/boot/dts/dove.dtsi| 35
arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-dockstar.dts| 17 ++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30 +++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++
arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +++
arch/arm/boot/dts/kirkwood-is2.dts |2 +
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 +++
..
[PATCH v5 05/13] net: mv643xx_eth: proper initialization for Kirkwood SoCs
Ethernet controllers found on Kirkwood SoCs not only suffer from loosing MAC address register contents on clock gating but also some important registers are reset to values that would break ethernet. This patch clears the CLK125_BYPASS_EN bit for DT enabled Kirkwood only by using of_device_is_compatible() instead of #ifdefs. Non-DT Kirkwood is not affected as it installs a clock gating workaround because of the MAC address issue above. Other Orion SoCs do not suffer from register reset, do not have the bit in question, or do not have the register at all. Moreover, system controllers on PPC using this driver should also be protected from clearing that bit. Signed-off-by: Sebastian Hesselbarth --- Note: In contrast to the reset value of 0 for CLK125_BYPASS_EN bit as stated in Kirkwood datasheet, we confirmed that reset value is 1 instead. Either datasheet is wrong about it, there is some post-boot self-check or BootROM flips that bit. Changelog v4->v5: - check for device compatible instead of machine compatible (Suggested by Jason Gunthorpe) Cc: David Miller Cc: Lennert Buytenhek Cc: Jason Cooper Cc: Andrew Lunn Cc: Benjamin Herrenschmidt Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index fa8c84a..5b375ee 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -116,6 +116,8 @@ static char mv643xx_eth_driver_version[] = "1.4"; #define LINK_UP 0x0002 #define TXQ_COMMAND0x0048 #define TXQ_FIX_PRIO_CONF 0x004c +#define PORT_SERIAL_CONTROL1 0x004c +#define CLK125_BYPASS_EN 0x0010 #define TX_BW_RATE 0x0050 #define TX_BW_MTU 0x0058 #define TX_BW_BURST0x005c @@ -2701,6 +2703,15 @@ static int mv643xx_eth_probe(struct platform_device *pdev) mp->dev = dev; + /* Kirkwood resets some registers on gated clocks. Especially +* CLK125_BYPASS_EN must be cleared but is not available on +* all other SoCs/System Controllers using this driver. +*/ + if (of_device_is_compatible(pdev->dev.of_node, + "marvell,kirkwood-eth-port")) + wrlp(mp, PORT_SERIAL_CONTROL1, +rdlp(mp, PORT_SERIAL_CONTROL1) & ~CLK125_BYPASS_EN); + /* * Start with a default rate, and if there is a clock, allow * it to override the default. -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 06/13] net: mv643xx_eth: add DT parsing support
This adds device tree parsing support for the shared driver of mv643xx_eth.
As the bindings are slightly different from current PPC bindings new binding
documentation is also added. Following PPC-style device setup, the shared
driver now also adds port platform_devices and sets up port platform_data.
Signed-off-by: Sebastian Hesselbarth
---
Note: Although different, device tree bindings are compatible with PPC
bindings. As I do not have access to any PPC platform using mv643xx_eth,
I leave conversion ("phy" vs "phy-handle") and compatible string name
up to PPC guys.
Due to hang reports for modular built mvmdio and mv643xx_eth, I have
tested module loading/unloading/reloading on CuBox (Dove) and Dockstar
(Kirkwood) without any issues for the whole patch set.
Changelog:
v5->v4:
- add Kirkwood specific compatible string
v3->v4:
- separation of independent patches (phy, of_mdio, devm)
- stand-alone device tree binding compatible to existing mv64x60 binding
- device node match for shared driver only
- device node registration for port drivers
- properly return -EPROBE_DEFER on missing of phy (Reported by Simon Baatz)
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../devicetree/bindings/net/marvell-orion-net.txt | 85 +++
drivers/net/ethernet/marvell/mv643xx_eth.c | 153 +++-
2 files changed, 234 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/marvell-orion-net.txt
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
new file mode 100644
index 000..a73b79f
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -0,0 +1,85 @@
+Marvell Orion/Discovery ethernet controller
+=
+
+The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
+(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
+Discovery system controller chips (mv64[345]60).
+
+The Discovery ethernet controller is described with two levels of nodes. The
+first level describes the ethernet controller itself and the second level
+describes up to 3 ethernet port nodes within that controller. The reason for
+the multiple levels is that the port registers are interleaved within a single
+set of controller registers. Each port node describes port-specific properties.
+
+Note: The above separation is only true for Discovery system controllers.
+For Orion SoCs we stick to the separation, although there each controller has
+only one port associated. Multiple ports are implemented as multiple
single-port
+controllers. As Kirkwood has some issues with proper initialization after
reset,
+an extra compatible string is added for it.
+
+* Ethernet controller node
+
+Required controller properties:
+ - #address-cells: shall be 1.
+ - #size-cells: shall be 0.
+ - compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth".
+ - reg: address and length of the controller registers.
+
+Optional controller properties:
+ - clocks: phandle reference to the controller clock.
+ - marvell,tx-checksum-limit: max tx packet size for hardware checksum.
+
+* Ethernet port node
+
+Required port properties:
+ - device_type: shall be "network".
+ - compatible: shall be one of "marvell,orion-eth-port",
+ "marvell,kirkwood-eth-port".
+ - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
+ - interrupts: port interrupt.
+ - local-mac-address: 6 bytes MAC address.
+
+Optional port properties:
+ - marvell,tx-queue-size: size of the transmit ring buffer.
+ - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
+ - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
+ - marvell,rx-queue-size: size of the receive ring buffer.
+ - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
+ - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
+
+and
+
+ - phy-handle: phandle reference to ethernet PHY.
+
+or
+
+ - speed: port speed if no PHY connected.
+ - duplex: port mode if no PHY connected.
+
+* Node example:
+
+mdio-bus {
+ ...
+ ethphy: ethernet-phy@8 {
+ device_type = "ethernet-phy";
+ ...
+ };
+};
+
+eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x2000>;
+ clocks = <&gate_clk 2>;
+ marvell,tx-checksum-limit = <1600>;
+
+ ethernet@0 {
+ device_type = "network";
+
[PATCH v5 07/13] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v3->v4:
- convert to new device tree binding
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/dove-cubox.dts |7 +++
arch/arm/boot/dts/dove.dtsi | 35 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 7e3065a..02618fa 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -49,6 +49,13 @@
&uart0 { status = "okay"; };
&sata0 { status = "okay"; };
&i2c0 { status = "okay"; };
+&mdio { status = "okay"; };
+ð { status = "okay"; };
+
+ðphy {
+ compatible = "marvell,88e1310";
+ reg = <1>;
+};
&sdio0 {
status = "okay";
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..8612658 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,40 @@
dmacap,xor;
};
};
+
+ mdio: mdio-bus@72004 {
+ compatible = "marvell,orion-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72004 0x84>;
+ interrupts = <30>;
+ clocks = <&gate_clk 2>;
+ status = "disabled";
+
+ ethphy: ethernet-phy {
+ device-type = "ethernet-phy";
+ /* set phy address in board file */
+ };
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x4000>;
+ clocks = <&gate_clk 2>;
+ marvell,tx-checksum-limit = <1600>;
+ status = "disabled";
+
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg = <0>;
+ interrupts = <29>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <ðphy>;
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 08/13] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v4->v5:
- use Kirkwood specific compatible string
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-dockstar.dts| 17 +++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30 +++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++
arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +
arch/arm/boot/dts/kirkwood-is2.dts |2 +
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 ++
.../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 16 ++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-ns2.dts |2 +
arch/arm/boot/dts/kirkwood-ns2lite.dts |2 +
arch/arm/boot/dts/kirkwood-ns2max.dts |2 +
arch/arm/boot/dts/kirkwood-ns2mini.dts |2 +
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 16 ++
arch/arm/boot/dts/kirkwood-topkick.dts | 16 ++
arch/arm/boot/dts/kirkwood-ts219-6281.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219-6282.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 16 ++
arch/arm/boot/dts/kirkwood.dtsi| 52
25 files changed, 398 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts
b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 5f21d4e..03e1b68 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -87,3 +87,19 @@
gpios = <&gpio0 17 0>;
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 6875ac0..7c8bc17 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -217,3 +217,19 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@8 {
+ device_type = "ethernet-phy";
+ reg = <8>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts
b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 0196cf6..b5aebbc 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -91,3 +91,20 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ compatible = "marvell,88e1116";
+ reg = <0>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 289e51d..e0c93d4 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ethphy0: ethernet-phy@0 {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
+
+ ethphy1: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <1>;
+ };
+};
+
+ð0 {
+ status = "okay";
+ ethernet0-port@0 {
+ phy-handle = <ðphy0>;
+ };
+};
+
+ð1 {
+ status = "okay";
+ ethernet1-port@0 {
+ phy-handle = <ðphy1>;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts
b/arch/a
[PATCH v5 09/13] ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Orion5x boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth
---
Changelog:
v3->v4:
- convert to new device tree binding
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../dts/orion5x-lacie-ethernet-disk-mini-v2.dts| 17
arch/arm/boot/dts/orion5x.dtsi | 29
2 files changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
index 0077fc8..c7e2efd 100644
--- a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
+++ b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
@@ -53,3 +53,20 @@
};
};
};
+
+&mdio {
+ status = "okay";
+
+ ðphy: ethernet-phy {
+ device-type = "ethernet-phy";
+ reg = <8>;
+ };
+};
+
+ð {
+ status = "okay";
+
+ ethernet-port@0 {
+ phy-handle = <ðphy>;
+ };
+};
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 892c64e..6fe45d5 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -132,5 +132,34 @@
interrupts = <28>;
status = "okay";
};
+
+ mdio: mdio-bus@72004 {
+ compatible = "marvell,orion-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72004 0x84>;
+ interrupts = <22>;
+ status = "disabled";
+
+ /* add phy nodes in board file */
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = "marvell,orion-eth";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x72000 0x4000>;
+ marvell,tx-checksum-limit = <1600>;
+ status = "disabled";
+
+ ethernet-port@0 {
+ device_type = "network";
+ compatible = "marvell,orion-eth-port";
+ reg = <0>;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ /* set phy-handle property in board file */
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 10/13] ARM: dove: remove legacy mv643xx_eth setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards anymore.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-dove/board-dt.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 0b14280..048e942 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -34,10 +34,6 @@ static void __init dove_legacy_clk_init(void)
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CLOCK_GATING_BIT_GBE;
- orion_clkdev_add(NULL, "mv643xx_eth_port.0",
-of_clk_get_from_provider(&clkspec));
-
clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
orion_clkdev_add("0", "pcie",
of_clk_get_from_provider(&clkspec));
@@ -53,10 +49,6 @@ static void __init dove_of_clk_init(void)
dove_legacy_clk_init();
}
-static struct mv643xx_eth_platform_data dove_dt_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
-};
-
static void __init dove_dt_init(void)
{
pr_info("Dove 88AP510 SoC\n");
@@ -70,7 +62,6 @@ static void __init dove_dt_init(void)
dove_of_clk_init();
/* Internal devices not ported to DT yet */
- dove_ge00_init(&dove_dt_ge00_data);
dove_pcie_init(1, 1);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 13/13] ARM: orion5x: remove legacy mv643xx_eth board setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards. This patch removes eth setup
for all orion5x DT board files.
Signed-off-by: Sebastian Hesselbarth
---
Cc: David Miller
Cc: Lennert Buytenhek
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Benjamin Herrenschmidt
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-orion5x/edmini_v2-setup.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c
b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..d9de926 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -96,14 +95,6 @@ static struct platform_device edmini_v2_nor_flash = {
};
/*
- * Ethernet
- /
-
-static struct mv643xx_eth_platform_data edmini_v2_eth_data = {
- .phy_addr = 8,
-};
-
-/*
* RTC 5C372a on I2C bus
/
@@ -152,7 +143,6 @@ void __init edmini_v2_init(void)
* Configure peripherals.
*/
orion5x_ehci0_init();
- orion5x_eth_init(&edmini_v2_eth_data);
mvebu_mbus_add_window("devbus-boot", EDMINI_V2_NOR_BOOT_BASE,
EDMINI_V2_NOR_BOOT_SIZE);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 11/13] ARM: kirkwood: remove legacy clk alias for mv643xx_eth
With all boards converted to DT enabled mv643xx_eth we can now remove the clock alias for gbe clocks. Signed-off-by: Sebastian Hesselbarth --- Cc: David Miller Cc: Lennert Buytenhek Cc: Jason Cooper Cc: Andrew Lunn Cc: Benjamin Herrenschmidt Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/mach-kirkwood/board-dt.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c index e9647b8..8db388a 100644 --- a/arch/arm/mach-kirkwood/board-dt.c +++ b/arch/arm/mach-kirkwood/board-dt.c @@ -66,12 +66,10 @@ static void __init kirkwood_legacy_clk_init(void) */ clkspec.args[0] = CGC_BIT_GE0; clk = of_clk_get_from_provider(&clkspec); - orion_clkdev_add(NULL, "mv643xx_eth_port.0", clk); clk_prepare_enable(clk); clkspec.args[0] = CGC_BIT_GE1; clk = of_clk_get_from_provider(&clkspec); - orion_clkdev_add(NULL, "mv643xx_eth_port.1", clk); clk_prepare_enable(clk); } -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files
With DT support for mv643xx_eth board specific init for some boards now is unneccessary. Remove those board files, Kconfig entries, and corresponding entries in kirkwood_defconfig. Signed-off-by: Sebastian Hesselbarth --- Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed the lock-up is not caused by accessing clock gating registers but rather non-existent device registers. This will be addressed by dtsi separation for kirkwood and bobcat SoC variants. Changelog: v3->v4: - remove more boards that don't require board specific setup Cc: David Miller Cc: Lennert Buytenhek Cc: Jason Cooper Cc: Andrew Lunn Cc: Benjamin Herrenschmidt Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/configs/kirkwood_defconfig | 16 arch/arm/mach-kirkwood/Kconfig| 117 - arch/arm/mach-kirkwood/Makefile | 16 arch/arm/mach-kirkwood/board-dnskw.c |7 -- arch/arm/mach-kirkwood/board-dockstar.c | 32 --- arch/arm/mach-kirkwood/board-dreamplug.c | 35 arch/arm/mach-kirkwood/board-dt.c | 62 + arch/arm/mach-kirkwood/board-goflexnet.c | 34 --- arch/arm/mach-kirkwood/board-guruplug.c | 33 --- arch/arm/mach-kirkwood/board-ib62x0.c | 29 -- arch/arm/mach-kirkwood/board-iconnect.c | 10 --- arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 34 --- arch/arm/mach-kirkwood/board-km_kirkwood.c| 44 -- arch/arm/mach-kirkwood/board-lsxl.c | 16 arch/arm/mach-kirkwood/board-mplcec4.c| 14 --- arch/arm/mach-kirkwood/board-ns2.c| 35 arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 -- arch/arm/mach-kirkwood/board-readynas.c |6 -- arch/arm/mach-kirkwood/board-ts219.c | 13 --- arch/arm/mach-kirkwood/board-usi_topkick.c| 29 -- 20 files changed, 1 insertion(+), 607 deletions(-) delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig index a1d8252..540ca51 100644 --- a/arch/arm/configs/kirkwood_defconfig +++ b/arch/arm/configs/kirkwood_defconfig @@ -30,27 +30,11 @@ CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_T5325=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y -CONFIG_MACH_CLOUDBOX_DT=y CONFIG_MACH_DLINK_KIRKWOOD_DT=y -CONFIG_MACH_DOCKSTAR_DT=y -CONFIG_MACH_DREAMPLUG_DT=y -CONFIG_MACH_GOFLEXNET_DT=y -CONFIG_MACH_GURUPLUG_DT=y -CONFIG_MACH_IB62X0_DT=y -CONFIG_MACH_ICONNECT_DT=y -CONFIG_MACH_INETSPACE_V2_DT=y -CONFIG_MACH_IOMEGA_IX2_200_DT=y -CONFIG_MACH_KM_KIRKWOOD_DT=y CONFIG_MACH_LSXL_DT=y CONFIG_MACH_MPLCEC4_DT=y -CONFIG_MACH_NETSPACE_LITE_V2_DT=y -CONFIG_MACH_NETSPACE_MAX_V2_DT=y -CONFIG_MACH_NETSPACE_MINI_V2_DT=y -CONFIG_MACH_NETSPACE_V2_DT=y CONFIG_MACH_NSA310_DT=y -CONFIG_MACH_OPENBLOCKS_A6_DT=y CONFIG_MACH_READYNAS_DT=y -CONFIG_MACH_TOPKICK_DT=y CONFIG_MACH_TS219_DT=y # CONFIG_CPU_FEROCEON_OLD_ID is not set CONFIG_PREEMPT=y diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index 7509a89..c2fd30b 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -146,13 +146,6 @@ config ARCH_KIRKWOOD_DT Say 'Y' here if you want your kernel to support the Marvell Kirkwood using flattened device tree. -config MACH_CLOUDBOX_DT - bool "LaCie CloudBox NAS (Flattened Device Tree)" - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the LaCie - CloudBox NAS, using Flattened Device Tree. - config MACH_DLINK_KIRKWOOD_DT bool "D-Link Kirkwood-based NAS (Flattened Device Tree)" select ARCH_KIRKWOOD_DT @@ -161,69 +154,6 @@ config MACH_DLINK_KIRKWOOD_DT Kirkwood-based D-Link NASes such as DNS-320 & DNS-325, using Flattened Device Tree. -config MACH_DOCKSTAR_DT - bool "Seagate FreeAgent Dockstar (Flattened Device Tree)" - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the - Seagate FreeAgent Dockstar (Flattened Device Tree). - -config MACH_DREAMPLUG_DT - bool "Marvell DreamPlug (Flattene
Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files
On 05/30/13 11:06, Arnaud Ebalard wrote: Sebastian Hesselbarth writes: With DT support for mv643xx_eth board specific init for some boards now is unneccessary. Remove those board files, Kconfig entries, and corresponding entries in kirkwood_defconfig. Signed-off-by: Sebastian Hesselbarth ... Just a stupid note: With Thomas ongoing work to get mvebu-pcie driver in place and enabled for kirkwood, some boards setup files will also lose their pcie init routines, which may allow you to kill those additonal files soon. For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes the PCIE init routine in board-readynas.c, and yours remove ge00 init. With both applied, the whole file can go away. AFAICT, this may be the case soon for: arch/arm/mach-kirkwood/board-iconnect.c (36e5722089) arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d) arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2) arch/arm/mach-kirkwood/board-readynas.c (6bd98481ab) arch/arm/mach-kirkwood/board-ts219.c (259e234608) Anyway, thanks for this work Sebastian. Arnaud, I already realized this when merging Jason's recent PRs and put mv643xx_eth patches on top. I am aware of it but as ARM part of mv643xx_eth will be delayed until net part surfaces, we have plenty of time to react on current updates to mach-kirkwood boards. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
On 05/31/2013 02:55 AM, David Miller wrote: From: Sebastian Hesselbarth Date: Wed, 29 May 2013 21:32:42 +0200 For the patches above I suggest to take Patches 1-6 through David Miller's branch, and Patches 7-12 through Jason Cooper's when the former have appeared on mainline linux. The patch set has been based on v3.10-rc3. Patches 1-6 applied to net-next, and patch #1 queued up for -stable. David, thanks for pulling these in. I finally found how to check if a patch already went into -stable. As Jason already said, the mdio patch that #1 fixes did not yet went into -stable. Can you unqueue it? Sorry for the confusion. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
On 11/05/2013 01:27 AM, Jason Gunthorpe wrote:
Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
present' made the call to phy_scan optional, if the DT has a link to
the phy node.
However phy_scan has the side effect of calling phy_addr_set, which
writes the phy MDIO address to the ethernet controller. If phy_addr_set
is not called, and the bootloader has not set the correct address then
the driver will fail to function.
Tested on Kirkwood.
Signed-off-by: Jason Gunthorpe
---
Jason,
thanks for catching this! I do my kirkwood testing on Dockstar,
which has PHY addr 0x0 - also the reset default, which may be
why it slipped through.
Acked-by: Sebastian Hesselbarth
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 2c210ec..00e43b5 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2890,6 +2890,7 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
PHY_INTERFACE_MODE_GMII);
if (!mp->phy)
err = -ENODEV;
+ phy_addr_set(mp, mp->phy->addr);
} else if (pd->phy_addr != MV643XX_ETH_PHY_NONE) {
mp->phy = phy_scan(mp, pd->phy_addr);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add missing phy_addr_set in DT mode
On 11/05/2013 11:12 PM, Arnaud Ebalard wrote: Hi Jason, Jason Gunthorpe writes: Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node present' made the call to phy_scan optional, if the DT has a link to the phy node. However phy_scan has the side effect of calling phy_addr_set, which writes the phy MDIO address to the ethernet controller. If phy_addr_set is not called, and the bootloader has not set the correct address then the driver will fail to function. Thanks *a lot* for fixing this one! I had the issue on my ReadyNAS 102 (Armada 370 based) which I had put on a todo list and temporarily Erm, just to make sure: Armada 370 isn't using mv643xx_eth but mvneta, are you sure it is (was) related to Jason's fix? Sebastian workarounded by including a 'ping whatever' call in my u-boot env in order to force it to do the init. Without it, I was unable to properly use the interface. With your fix, after multiple reboots to test it, everything works as expected. So, FWIW: Tested-by: Arnaud Ebalard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/11/2014 11:33 PM, Kumar Gala wrote:
On Feb 11, 2014, at 2:57 PM, Stephen N Chivers wrote:
I have been trial booting a 3.14-rc2 kernel for a 85xx platform
(dtbImage).
After mounting the root filesystem there are no messages from the init
scripts
and the serial console is not available for login.
In the kernel log messages there is:
of_serial f1004500.serial: Unknown serial port found, ignored.
The serial nodes in boards dts file are specified as:
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
interrupts = <0x2a 0x2>;
interrupt-parent = <&mpic>;
};
Reversing the order of the compatible:
compatible = "ns16550", "fsl,ns16550";
restores the serial console.
Linux-3.13 does not have this behaviour.
There are 49 dts files in Linux-3.14-rc2 that have the fsl,ns16550
compatible first.
Hmm,
Wondering if this caused the issue:
commit 105353145eafb3ea919f5cdeb652a9d8f270228e
Author: Sebastian Hesselbarth
Date: Tue Dec 3 14:52:00 2013 +0100
OF: base: match each node compatible against all given matches first
[adding Arnd on Cc]
Could be. I checked tty/serial/of_serial.c and it does not provide a
compatible for "fsl,ns16550". Does reverting the patch fix the issue
observed?
I don't think the missing compatible is causing it, but of_serial
provides a DT match for .type = "serial" just to fail later on
with the error seen above.
The commit in question reorders of_match_device in a way that match
table order is not relevant anymore. This can cause it to match
.type = "serial" first here.
Rather than touching the commit, I suggest to remove the problematic
.type = "serial" from the match table. It is of no use anyway.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/12/2014 12:38 AM, Stephen N Chivers wrote:
Sebastian Hesselbarth wrote on
On 02/11/2014 11:33 PM, Kumar Gala wrote:
On Feb 11, 2014, at 2:57 PM, Stephen N Chivers wrote:
I have been trial booting a 3.14-rc2 kernel for a 85xx platform
(dtbImage).
[...]
of_serial f1004500.serial: Unknown serial port found, ignored.
The serial nodes in boards dts file are specified as:
serial0: serial@4500 {
cell-index = <0>;
device_type = "serial";
compatible = "fsl,ns16550", "ns16550";
reg = <0x4500 0x100>;
clock-frequency = <0>;
interrupts = <0x2a 0x2>;
interrupt-parent = <&mpic>;
};
Wondering if this caused the issue:
commit 105353145eafb3ea919f5cdeb652a9d8f270228e
Author: Sebastian Hesselbarth
Date: Tue Dec 3 14:52:00 2013 +0100
OF: base: match each node compatible against all given matches first
[...]
I don't think the missing compatible is causing it, but of_serial
provides a DT match for .type = "serial" just to fail later on
with the error seen above.
The commit in question reorders of_match_device in a way that match
table order is not relevant anymore. This can cause it to match
.type = "serial" first here.
Rather than touching the commit, I suggest to remove the problematic
.type = "serial" from the match table. It is of no use anyway.
Deleting the "serial" line from the match table fixes the problem.
I tested it for both orderings of compatible.
I revert my statement about removing anything from of_serial.c. Instead
we should try to prefer matches with compatibles over type/name without
compatibles. Something like the patch below (compile tested only)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450d5683..60da53b385ff 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -734,6 +734,7 @@ static
const struct of_device_id *__of_match_node(const struct of_device_id *matches,
const struct device_node *node)
{
+ const struct of_device_id *m;
const char *cp;
int cplen, l;
@@ -742,15 +743,15 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
cp = __of_get_property(node, "compatible", &cplen);
do {
- const struct of_device_id *m = matches;
+ m = matches;
/* Check against matches with current compatible string */
while (m->name[0] || m->type[0] || m->compatible[0]) {
int match = 1;
- if (m->name[0])
+ if (m->name[0] && m->compatible[0])
match &= node->name
&& !strcmp(m->name, node->name);
- if (m->type[0])
+ if (m->type[0] && m->compatible[0])
match &= node->type
&& !strcmp(m->type, node->type);
if (m->compatible[0])
@@ -770,6 +771,21 @@ const struct of_device_id *__of_match_node(const struct of_device_id *matches,
}
} while (cp && (cplen > 0));
+ /* Check against matches without compatible string */
+ m = matches;
+ while (m->name[0] || m->type[0]) {
+ int match = 1;
+ if (m->name[0])
+ match &= node->name
+&& !strcmp(m->name, node->name);
+ if (m->type[0])
+ match &= node->type
+&& !strcmp(m->type, node->type);
+ if (match)
+ return m;
+ m++;
+ }
+
return NULL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/12/2014 12:41 AM, Scott Wood wrote: On Tue, 2014-02-11 at 23:51 +0100, Sebastian Hesselbarth wrote: On 02/11/2014 11:33 PM, Kumar Gala wrote: Hmm, Wondering if this caused the issue: commit 105353145eafb3ea919f5cdeb652a9d8f270228e Author: Sebastian Hesselbarth Date: Tue Dec 3 14:52:00 2013 +0100 OF: base: match each node compatible against all given matches first [adding Arnd on Cc] Could be. I checked tty/serial/of_serial.c and it does not provide a compatible for "fsl,ns16550". Does reverting the patch fix the issue observed? I don't think the missing compatible is causing it, but of_serial provides a DT match for .type = "serial" just to fail later on with the error seen above. The commit in question reorders of_match_device in a way that match table order is not relevant anymore. This can cause it to match .type = "serial" first here. Rather than touching the commit, I suggest to remove the problematic .type = "serial" from the match table. It is of no use anyway. Regardless of whether .type = "serial" gets removed, it seems wrong for of_match_node() to accept a .type-only match (or .name, or anything else that doesn't involve .compatible) before it accepts a compatible match other than the first in the compatible property. Right, I thought about it and came to the same conclusion. I sent a patch a second ago to prefer .compatible != NULL matches over those with .compatible == NULL. Would be great if Stephen can re-test that. If it solves the issue, I can send a patch tomorrow. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/12/2014 01:21 AM, Stephen N Chivers wrote:
Sebastian Hesselbarth wrote on
02/12/2014 10:46:36 AM:
From: Sebastian Hesselbarth
To: Scott Wood
Cc: Kumar Gala , Stephen N Chivers
, Chris Proctor ,
linuxppc-dev@lists.ozlabs.org, Arnd Bergmann ,
devicetree
Date: 02/12/2014 11:04 AM
Subject: Re: Linux-3.14-rc2: Order of serial node compatibles in DTS
files.
On 02/12/2014 12:41 AM, Scott Wood wrote:
Regardless of whether .type = "serial" gets removed, it seems wrong for
of_match_node() to accept a .type-only match (or .name, or anything else
that doesn't involve .compatible) before it accepts a compatible match
other than the first in the compatible property.
Right, I thought about it and came to the same conclusion. I sent a
patch a second ago to prefer .compatible != NULL matches over those
with .compatible == NULL.
Would be great if Stephen can re-test that. If it solves the issue, I
can send a patch tomorrow.
Done.
But, the Interrupt Controller (MPIC)
goes AWOL and it is down hill from there.
The MPIC is specified in the DTS as:
mpic: pic@4 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x4 0x4>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
The board support file has the standard mechanism for allocating
the PIC:
struct mpic *mpic;
mpic = mpic_alloc(NULL, 0, 0, 0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
I checked for damage in applying the patch and it has applied
correctly.
Hmm, I did a mistake in the patch:
- while (m->name[0] || m->type[0]) {
+ while (m->compatible[0] || m->name[0] || m->type[0]) {
for the second added match. Otherwise, the matches are not
evaluated down to the sentinel but the loop quits on the first
match table entry without .name and .type set.
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/12/2014 06:28 AM, Kevin Hao wrote:
On Wed, Feb 12, 2014 at 10:21:58AM +1000, Stephen N Chivers wrote:
But, the Interrupt Controller (MPIC)
goes AWOL and it is down hill from there.
The MPIC is specified in the DTS as:
mpic: pic@4 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x4 0x4>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
The board support file has the standard mechanism for allocating
the PIC:
struct mpic *mpic;
mpic = mpic_alloc(NULL, 0, 0, 0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
I checked for damage in applying the patch and it has applied
correctly.
How about the following fix?
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450d5683..ca91984d3c4b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,32 +730,40 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static int of_match_type_name(const struct device_node *node,
+ const struct of_device_id *m)
I am fine with having a sub-function here, but it should rather be
named of_match_type_or_name.
+{
+ int match = 1;
+
+ if (m->name[0])
+ match &= node->name && !strcmp(m->name, node->name);
+
+ if (m->type[0])
+ match &= node->type && !strcmp(m->type, node->type);
+
+ return match;
+}
[...]
+ /* Check against matches without compatible string */
+ m = matches;
+ while (!m->compatible[0] && (m->name[0] || m->type[0])) {
We shouldn't check for anything else than the sentinel here.
Although I guess yours will not quit early as mine did but that
way we don't have to worry about it.
Sebastian
+ match = of_match_type_name(node, m);
+ if (match)
+ return m;
+ m++;
+ }
+
return NULL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On 02/12/14 11:31, Kevin Hao wrote:
On Wed, Feb 12, 2014 at 09:30:00AM +0100, Sebastian Hesselbarth wrote:
On 02/12/2014 06:28 AM, Kevin Hao wrote:
On Wed, Feb 12, 2014 at 10:21:58AM +1000, Stephen N Chivers wrote:
But, the Interrupt Controller (MPIC)
goes AWOL and it is down hill from there.
The MPIC is specified in the DTS as:
mpic: pic@4 {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <0x4 0x4>;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
The board support file has the standard mechanism for allocating
the PIC:
struct mpic *mpic;
mpic = mpic_alloc(NULL, 0, 0, 0, 256, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
I checked for damage in applying the patch and it has applied
correctly.
How about the following fix?
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450d5683..ca91984d3c4b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,32 +730,40 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static int of_match_type_name(const struct device_node *node,
+ const struct of_device_id *m)
I am fine with having a sub-function here, but it should rather be
named of_match_type_or_name.
OK.
+{
+ int match = 1;
+
+ if (m->name[0])
+ match &= node->name && !strcmp(m->name, node->name);
+
+ if (m->type[0])
+ match &= node->type && !strcmp(m->type, node->type);
+
+ return match;
+}
[...]
+ /* Check against matches without compatible string */
+ m = matches;
+ while (!m->compatible[0] && (m->name[0] || m->type[0])) {
We shouldn't check for anything else than the sentinel here.
Although I guess yours will not quit early as mine did but that
way we don't have to worry about it.
Yes, this is still buggy. I will change something like this:
m = matches;
/* Check against matches without compatible string */
while (m->name[0] || m->type[0] || m->compatible[0]) {
if (m->compatible[0]) {
m++;
continue;
}
match = of_match_type_name(node, m);
if (match)
return m;
m++;
}
You can cook it down to:
m = matches;
/* Check against matches without compatible string */
while (m->name[0] || m->type[0] || m->compatible[0]) {
if (!m->compatible[0] && of_match_type_or_name(node, m)
return m;
m++;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
On 15.01.2016 05:01, Shaohui Xie wrote: >> -Original Message- >> From: Andrew Lunn [mailto:and...@lunn.ch] >> Sent: Friday, January 15, 2016 12:44 AM >> To: shh@gmail.com >> Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc- >> d...@lists.ozlabs.org; f.faine...@gmail.com; da...@davemloft.net; Shaohui Xie >> Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR >> >> On Thu, Jan 14, 2016 at 04:23:59PM +0800, shh@gmail.com wrote: >>> From: Shaohui Xie >>> >>> This commit adds necessary definitions for the PHY layer to recognize >>> backplane Ethernet 1000BASE-KX and 10GBASE-KR as valid PHY interfaces, >>> "1000base-kx" for 1000BASE-KX, "10gbase-kr" for 10GBASE-KR. >>> >>> Signed-off-by: Shaohui Xie >>> --- >>> changes in v2: >>> new patch. Shaohui, it would be more useful to describe _what_ is new here compared to v1. Anyway: >>> Documentation/devicetree/bindings/net/ethernet.txt | 4 ++-- >>> include/linux/phy.h| 6 ++ >>> 2 files changed, 8 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt >>> b/Documentation/devicetree/bindings/net/ethernet.txt >>> index 5d88f37..1166a5c 100644 >>> --- a/Documentation/devicetree/bindings/net/ethernet.txt >>> +++ b/Documentation/devicetree/bindings/net/ethernet.txt >>> @@ -11,8 +11,8 @@ The following properties are common to the Ethernet >> controllers: >>>the maximum frame size (there's contradiction in ePAPR). >>> - phy-mode: string, operation mode of the PHY interface; supported values >>> are >>>"mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", >>> "rgmii", "rgmii-id", >>> - "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a >>> de-facto >>> - standard property; >>> + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii", "1000base-kx", >>> + "10gbase-kr"; this is now a de-facto standard property; >> >> I know very little about this, so i'm just asking a question. None of the >> other >> interface modes contain a bit rate. So is the bit rate needed for your two >> new >> modes? > > 1000BASE-KX and 10GBASE-KR are terms in IEEE802.3, so as XGMII and GMII. > There are interfaces could be different bit rates but same types, > e.g. 100BASE-LX10 and 1000BASE-LX10, or 40GBASE-KR4 and 100GBASE-KR4, > having bit rate is clear to represent hardware. > If you look at the list of possible values for "phy-mode" you'd see that none of it describes a PHY-to-PHY connection but all are for MAC-to-PHY connections. Also, names above suggest it already: MII is short for media _independent_ interface. I copy Andrew's concerns and think that neither 1base-kx nor 10gbase-kr belong in the list of phy-mode properties. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
On 18.01.2016 08:23, Shaohui Xie wrote:
If you look at the list of possible values for "phy-mode" you'd see
that none of it describes a PHY-to-PHY connection but all are for
MAC-to-PHY connections. Also, names above suggest it already: MII is
short for media _independent_ interface.
I copy Andrew's concerns and think that neither 1base-kx nor
10gbase-kr belong in the list of phy-mode properties.
I concur with that as well, if the phy connection does not really matter here,
or does not seem like a good fit, maybe we should have a different property, or
just define the hardware interface a little differently?
Right, 'phy-mode' is not a good fit for backplanes, how about a new property
like
'backplane-mode' or something, like below:
Hmm. We already have a speed property for that you can use for
1000, 1, 4. Leaves the media-type, e.g. copper or whatever.
Currently, you fail to convince me that it is required to describe
the media type at all. We have come a long way with different media
without describing the PHY-to-PHY media type.
What makes the backplane setup so special?
Sebastian
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -33,6 +33,9 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- backplane-mode: string, operation mode of the backplane PHY;
+ must be "1000base-kx" for 1000BASE-KX, or "10gbase-kr" for 10GBASE-KR.
+
Example:
ethernet-phy@0 {
Thank you!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
On 22.01.2016 09:15, Shaohui Xie wrote:
___
From: Andrew Lunn
Sent: Friday, January 22, 2016 5:12 AM
To: Shaohui Xie
Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
devicet...@vger.kernel.org; net...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
On Tue, Jan 19, 2016 at 05:00:35AM +, Shaohui Xie wrote:
-Original Message-
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Monday, January 18, 2016 11:15 PM
To: Shaohui Xie
Cc: Sebastian Hesselbarth; Florian Fainelli; shh@gmail.com;
devicet...@vger.kernel.org; net...@vger.kernel.org; linuxppc-
d...@lists.ozlabs.org; da...@davemloft.net; Shaohui Xie
Subject: Re: [PATCH 1/3][v2] net: phy: introduce 1000BASE-KX and 10GBASE-KR
[S.H] the fsl backplane, e.g. 10GBASE-KR, needs software to handle
link training, It's to train link partner, and trained by link partner
parallel.
But if media type is not copper, e.g. optical module, we won't need this.
So what we actually need to know is copper vs fibre?
Copper is not enough to indicate backplane, since backplane is
always copper, but copper is not always backplane.
O.K, lets try again
[S.H]Seems I did not get your point, Sorry for the inconvenient.
If it is copper backplane you need to perform training.
Looking at the driver probe function, it is either 1000BASE-KX, no
training needed, or else it is 10GBASE-RK and training is needed.
Looking at fsl_backplane_config_aneg() you expect phydev->speed to be
set, and from the speed you then kick of either KR autoneg or KX
autoneg. Could you also start the training at this point? Use the
speed to indicate if training is needed?
[S.H]The training cannot be started at this point, yet, because it's based on
autoneg result, only when both sides autoneg-ed to 10G-KR, then to start
the training.
Shaohui,
look, we want you to convince us why to have a generic backplane
property in the phy binding. You had a bad start by adding new
property values to a property that does not relate to your use
case at all. Your job now really is to give strong reasons _why_
and _what_ a phy driver needs to know about the backplane setup.
Your first approach was to add "10gbase-rk" or "40gbase-foo" but
now you tell us about ANEG. Of what use is the information given
by the property when ANEG tells you something different? E.g.
consider the property tells you "10g-something" but ANEG gives
you "40g"; does the property add any value to your training
decision now?
Besides the driver, generally speaking, "copper + speed" is not enough to
indicate
it's backplane, for ex. "copper + 1000" does not mean it has to be 1000BASE-KX,
it could be SGMII, hence cannot use KX autoneg.
So, is it copper + speed + backplane? or speed + backplane? And out of
the set of required input, is there anything your _cannot_ determine
from other things, e.g. ANEG?
If it is backplane only, would a boolean property ("backplane-mode")
be enough for the training decision?
If putting backplane property to phy.txt is not good, I can put it to fsl
specific
binding, like the second patch 2/3 did.
You seem to see vendor specific properties as a place to dump all your
waste you don't want to think about. You fail to give good reasons what
is so special about the backplane setup and now you are telling us that
it is even fsl-specific?
Sebastian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
