[PATCH 0/6] net: mvpp2: Assorted fixes

[PATCH 0/6] net: mvpp2: Assorted fixes

[Ezequiel Garcia]

This patchset contains a set of fixes for issues found while doing some
more intensive tests on the recently accepted mvpp2 ethernet driver.

David: if we are still in time, we'd like to get the driver fixes merged
for v3.17-rc1.

For the devicetree changes, it's already too late for that, since Jason
Cooper has already posted the PRs for v3.17. I'll re-post them when
v3.17-rc1 is released.

As usual, feedback is welcome.

Ezequiel Garcia (3):
  net: mvpp2: Fix the BM pool buffer release check
  net: mvpp2: Simplify BM pool buffers freeing
  ARM: mvebu: Add missing MDIO clock in Armada 375

Marcin Wojtas (3):
  net: mvpp2: Fix the periodic XON enable bit
  net: mvpp2: Enable proper PHY polling and fix port functionality
  ARM: mvebu: Add ethernet aliases required by U-Boot

 arch/arm/boot/dts/armada-375.dtsi    |  3 ++
 drivers/net/ethernet/marvell/mvpp2.c | 65 +++++++++++++++++++++++-------------
 2 files changed, 44 insertions(+), 24 deletions(-)

-- 
2.0.1

[PATCH 1/6] net: mvpp2: Fix the periodic XON enable bit

[Ezequiel Garcia]

From: Marcin Wojtas <mw@semihalf.com>

This bit was originally wrong, the correct value is BIT(1), so fix it.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index f4de2a9..8eac438 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -262,7 +262,7 @@
 #define      MVPP2_GMAC_MAX_RX_SIZE_MASK	0x7ffc
 #define      MVPP2_GMAC_MIB_CNTR_EN_MASK	BIT(15)
 #define MVPP2_GMAC_CTRL_1_REG			0x4
-#define      MVPP2_GMAC_PERIODIC_XON_EN_MASK	BIT(0)
+#define      MVPP2_GMAC_PERIODIC_XON_EN_MASK	BIT(1)
 #define      MVPP2_GMAC_GMII_LB_EN_MASK		BIT(5)
 #define      MVPP2_GMAC_PCS_LB_EN_BIT		6
 #define      MVPP2_GMAC_PCS_LB_EN_MASK		BIT(6)
-- 
2.0.1

[PATCH 2/6] net: mvpp2: Enable proper PHY polling and fix port functionality

[Ezequiel Garcia]

From: Marcin Wojtas <mw@semihalf.com>

Currently, the network interfaces that are not configured by the bootloader
(using e.g. tftp or ping) can detect the link status but are unable to
transmit data.

The network controller has a functionality that allows the hardware to
continuously poll the PHY and directly update the MAC configuration accordingly
(speed, duplex, etc.). However, this doesn't work well with phylib's
software-based polling and updating MAC configuration in the driver's callback.

This commit fixes this issue by:

  1. Setting MVPP2_PHY_AN_STOP_SMI0_MASK in MVPP2_PHY_AN_CFG0_REG in
     mvpp2_init(), which disables the harware polling feature.

  2. Disabling MVPP2_GMAC_PCS_ENABLE_MASK bit in MVPP2_GMAC_CTRL_2_REG in
     mvpp2_port_mii_set() for port types other than SGMII.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 40 ++++++++++++++++++++++++++++--------
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 8eac438..aa139df 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -248,6 +248,8 @@
 /* LMS registers */
 #define MVPP2_SRC_ADDR_MIDDLE			0x24
 #define MVPP2_SRC_ADDR_HIGH			0x28
+#define MVPP2_PHY_AN_CFG0_REG			0x34
+#define     MVPP2_PHY_AN_STOP_SMI0_MASK		BIT(7)
 #define MVPP2_MIB_COUNTERS_BASE(port)		(0x1000 + ((port) >> 1) * \
 						0x400 + (port) * 0x400)
 #define     MVPP2_MIB_LATE_COLLISION		0x7c
@@ -278,6 +280,7 @@
 #define      MVPP2_GMAC_CONFIG_MII_SPEED	BIT(5)
 #define      MVPP2_GMAC_CONFIG_GMII_SPEED	BIT(6)
 #define      MVPP2_GMAC_AN_SPEED_EN		BIT(7)
+#define      MVPP2_GMAC_FC_ADV_EN		BIT(9)
 #define      MVPP2_GMAC_CONFIG_FULL_DUPLEX	BIT(12)
 #define      MVPP2_GMAC_AN_DUPLEX_EN		BIT(13)
 #define MVPP2_GMAC_PORT_FIFO_CFG_1_REG		0x1c
@@ -3809,16 +3812,30 @@ static void mvpp2_interrupts_unmask(void *arg)
 
 static void mvpp2_port_mii_set(struct mvpp2_port *port)
 {
-	u32 reg, val = 0;
+	u32 val;
 
-	if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
-		val = MVPP2_GMAC_PCS_ENABLE_MASK |
-		      MVPP2_GMAC_INBAND_AN_MASK;
-	else if (port->phy_interface == PHY_INTERFACE_MODE_RGMII)
-		val = MVPP2_GMAC_PORT_RGMII_MASK;
+	val = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
+
+	switch (port->phy_interface) {
+	case PHY_INTERFACE_MODE_SGMII:
+		val |= MVPP2_GMAC_INBAND_AN_MASK;
+		break;
+	case PHY_INTERFACE_MODE_RGMII:
+		val |= MVPP2_GMAC_PORT_RGMII_MASK;
+	default:
+		val &= ~MVPP2_GMAC_PCS_ENABLE_MASK;
+	}
+
+	writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
+}
 
-	reg = readl(port->base + MVPP2_GMAC_CTRL_2_REG);
-	writel(reg | val, port->base + MVPP2_GMAC_CTRL_2_REG);
+static void mvpp2_port_fc_adv_enable(struct mvpp2_port *port)
+{
+	u32 val;
+
+	val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
+	val |= MVPP2_GMAC_FC_ADV_EN;
+	writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
 }
 
 static void mvpp2_port_enable(struct mvpp2_port *port)
@@ -5877,6 +5894,7 @@ static void mvpp2_port_power_up(struct mvpp2_port *port)
 {
 	mvpp2_port_mii_set(port);
 	mvpp2_port_periodic_xon_disable(port);
+	mvpp2_port_fc_adv_enable(port);
 	mvpp2_port_reset(port);
 }
 
@@ -6198,6 +6216,7 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
 {
 	const struct mbus_dram_target_info *dram_target_info;
 	int err, i;
+	u32 val;
 
 	/* Checks for hardware constraints */
 	if (rxq_number % 4 || (rxq_number > MVPP2_MAX_RXQ) ||
@@ -6211,6 +6230,11 @@ static int mvpp2_init(struct platform_device *pdev, struct mvpp2 *priv)
 	if (dram_target_info)
 		mvpp2_conf_mbus_windows(dram_target_info, priv);
 
+	/* Disable HW PHY polling */
+	val = readl(priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
+	val |= MVPP2_PHY_AN_STOP_SMI0_MASK;
+	writel(val, priv->lms_base + MVPP2_PHY_AN_CFG0_REG);
+
 	/* Allocate and initialize aggregated TXQs */
 	priv->aggr_txqs = devm_kcalloc(&pdev->dev, num_present_cpus(),
 				       sizeof(struct mvpp2_tx_queue),
-- 
2.0.1

[PATCH 3/6] net: mvpp2: Fix the BM pool buffer release check

[Ezequiel Garcia]

After a call to mvpp2_bm_bufs_free(), the caller usually wants to know
if the function successfully freed the requested number. However, this
cannot be done by looking into the BM pool count, because the current
buffer count was updated by mvpp2_bm_bufs_free().

In fact, the current callers of mvpp2_bm_bufs_free() use it to release
all the buffers in the pool, so we can fix this by simply checking
if the pool is not empty.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index aa139df..43d3391 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -3420,7 +3420,7 @@ static int mvpp2_bm_pool_destroy(struct platform_device *pdev,
 	u32 val;
 
 	num = mvpp2_bm_bufs_free(priv, bm_pool, bm_pool->buf_num);
-	if (num != bm_pool->buf_num) {
+	if (bm_pool->buf_num) {
 		WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id);
 		return 0;
 	}
@@ -3748,8 +3748,8 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)
 	int pkt_size = MVPP2_RX_PKT_SIZE(mtu);
 
 	/* Update BM pool with new buffer size */
-	num = mvpp2_bm_bufs_free(port->priv, port_pool, pkts_num);
-	if (num != pkts_num) {
+	mvpp2_bm_bufs_free(port->priv, port_pool, pkts_num);
+	if (port_pool->buf_num) {
 		WARN(1, "cannot free all buffers in pool %d\n", port_pool->id);
 		return -EIO;
 	}
-- 
2.0.1

[PATCH 4/6] net: mvpp2: Simplify BM pool buffers freeing

[Ezequiel Garcia]

Now that all the users of mvpp2_bm_bufs_free() have been fixed, we can safely
clean the function prototype.

The function is always called to release all the buffers in a BM pool, and
the number of buffers freed is not needed. Therefore, we change the return
to a void, and remove the "num" parameter. This is a cosmetic change, to
make the code slightly cleaner.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 19 ++++++-------------
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
index 43d3391..b009eee 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -3385,17 +3385,12 @@ static void mvpp2_bm_pool_bufsize_set(struct mvpp2 *priv,
 	mvpp2_write(priv, MVPP2_POOL_BUF_SIZE_REG(bm_pool->id), val);
 }
 
-/* Free "num" buffers from the pool */
-static int mvpp2_bm_bufs_free(struct mvpp2 *priv,
-			      struct mvpp2_bm_pool *bm_pool, int num)
+/* Free all buffers from the pool */
+static void mvpp2_bm_bufs_free(struct mvpp2 *priv, struct mvpp2_bm_pool *bm_pool)
 {
 	int i;
 
-	if (num >= bm_pool->buf_num)
-		/* Free all buffers from the pool */
-		num = bm_pool->buf_num;
-
-	for (i = 0; i < num; i++) {
+	for (i = 0; i < bm_pool->buf_num; i++) {
 		u32 vaddr;
 
 		/* Get buffer virtual adress (indirect access) */
@@ -3408,7 +3403,6 @@ static int mvpp2_bm_bufs_free(struct mvpp2 *priv,
 
 	/* Update BM driver with number of buffers removed from pool */
 	bm_pool->buf_num -= i;
-	return i;
 }
 
 /* Cleanup pool */
@@ -3416,10 +3410,9 @@ static int mvpp2_bm_pool_destroy(struct platform_device *pdev,
 				 struct mvpp2 *priv,
 				 struct mvpp2_bm_pool *bm_pool)
 {
-	int num;
 	u32 val;
 
-	num = mvpp2_bm_bufs_free(priv, bm_pool, bm_pool->buf_num);
+	mvpp2_bm_bufs_free(priv, bm_pool);
 	if (bm_pool->buf_num) {
 		WARN(1, "cannot free all buffers in pool %d\n", bm_pool->id);
 		return 0;
@@ -3675,7 +3668,7 @@ mvpp2_bm_pool_use(struct mvpp2_port *port, int pool, enum mvpp2_bm_type type,
 				   MVPP2_BM_LONG_BUF_NUM :
 				   MVPP2_BM_SHORT_BUF_NUM;
 		else
-			mvpp2_bm_bufs_free(port->priv, new_pool, pkts_num);
+			mvpp2_bm_bufs_free(port->priv, new_pool);
 
 		new_pool->pkt_size = pkt_size;
 
@@ -3748,7 +3741,7 @@ static int mvpp2_bm_update_mtu(struct net_device *dev, int mtu)
 	int pkt_size = MVPP2_RX_PKT_SIZE(mtu);
 
 	/* Update BM pool with new buffer size */
-	mvpp2_bm_bufs_free(port->priv, port_pool, pkts_num);
+	mvpp2_bm_bufs_free(port->priv, port_pool);
 	if (port_pool->buf_num) {
 		WARN(1, "cannot free all buffers in pool %d\n", port_pool->id);
 		return -EIO;
-- 
2.0.1

[PATCH 5/6] ARM: mvebu: Add ethernet aliases required by U-Boot

[Ezequiel Garcia]

From: Marcin Wojtas <mw@semihalf.com>

The vendor bootloader provided for Armada 375 boards expect an
alias for the ethernet nodes, which is used to fixup the MAC address.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
 arch/arm/boot/dts/armada-375.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index d4619ad..bfcbe58 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -25,6 +25,8 @@
 		gpio0 = &gpio0;
 		gpio1 = &gpio1;
 		gpio2 = &gpio2;
+		ethernet0 = &eth0;
+		ethernet1 = &eth1;
 	};
 
 	clocks {
-- 
2.0.1

[PATCH 6/6] ARM: mvebu: Add missing MDIO clock in Armada 375

[Ezequiel Garcia]

In Armada 375 SoCs, the MDIO is handled by a separate orion-mdio driver,
despite the register is contained within the "LMS" block of the network
controller.

Therefore we need to add the clock to the MDIO devicetree to prevent the
controller from being accesed with its clock gated. This is needed, for
instance, to be able to load the MDIO driver before the network driver.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 arch/arm/boot/dts/armada-375.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index bfcbe58..c1e49e7 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -158,6 +158,7 @@
 				#size-cells = <0>;
 				compatible = "marvell,orion-mdio";
 				reg = <0xc0054 0x4>;
+				clocks = <&gateclk 19>;
 			};
 
 			/* Network controller */
-- 
2.0.1

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[David Miller]

From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Mon, 21 Jul 2014 13:48:10 -0300

> This patchset contains a set of fixes for issues found while doing some
> more intensive tests on the recently accepted mvpp2 ethernet driver.
> 
> David: if we are still in time, we'd like to get the driver fixes merged
> for v3.17-rc1.
> 
> For the devicetree changes, it's already too late for that, since Jason
> Cooper has already posted the PRs for v3.17. I'll re-post them when
> v3.17-rc1 is released.
> 
> As usual, feedback is welcome.

This series does not apply to the 'net' tree at all, please respin
and resubmit.

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[Ezequiel Garcia]

On 21 Jul 08:27 PM, David Miller wrote:
> From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date: Mon, 21 Jul 2014 13:48:10 -0300
> 
> > This patchset contains a set of fixes for issues found while doing some
> > more intensive tests on the recently accepted mvpp2 ethernet driver.
> > 
> > David: if we are still in time, we'd like to get the driver fixes merged
> > for v3.17-rc1.
> > 
> > For the devicetree changes, it's already too late for that, since Jason
> > Cooper has already posted the PRs for v3.17. I'll re-post them when
> > v3.17-rc1 is released.
> > 
> > As usual, feedback is welcome.
> 
> This series does not apply to the 'net' tree at all, please respin
> and resubmit.

This series applies on net-next.

Sorry for not mentioning it,
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[David Miller]

From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Tue, 22 Jul 2014 11:45:19 -0300

> On 21 Jul 08:27 PM, David Miller wrote:
>> From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>> Date: Mon, 21 Jul 2014 13:48:10 -0300
>> 
>> > This patchset contains a set of fixes for issues found while doing some
>> > more intensive tests on the recently accepted mvpp2 ethernet driver.
>> > 
>> > David: if we are still in time, we'd like to get the driver fixes merged
>> > for v3.17-rc1.
>> > 
>> > For the devicetree changes, it's already too late for that, since Jason
>> > Cooper has already posted the PRs for v3.17. I'll re-post them when
>> > v3.17-rc1 is released.
>> > 
>> > As usual, feedback is welcome.
>> 
>> This series does not apply to the 'net' tree at all, please respin
>> and resubmit.
> 
> This series applies on net-next.
> 
> Sorry for not mentioning it,

They are bonafide bug fixes, therefore should be targetted at 'net'.

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[Thomas Petazzoni]

Dear David Miller,

On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:

> >> This series does not apply to the 'net' tree at all, please respin
> >> and resubmit.
> > 
> > This series applies on net-next.
> > 
> > Sorry for not mentioning it,
> 
> They are bonafide bug fixes, therefore should be targetted at 'net'.

Except that I believe they are fixes for a driver which itself is in
net-next, i.e scheduled for 3.17.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[Ezequiel Garcia]

On 23 Jul 12:29 AM, Thomas Petazzoni wrote:
> On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
> 
> > >> This series does not apply to the 'net' tree at all, please respin
> > >> and resubmit.
> > > 
> > > This series applies on net-next.
> > > 
> > > Sorry for not mentioning it,
> > 
> > They are bonafide bug fixes, therefore should be targetted at 'net'.
> 
> Except that I believe they are fixes for a driver which itself is in
> net-next, i.e scheduled for 3.17.
> 

That's right. These are fixes for the new mvpp2 driver, which is only
in net-next.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[David Miller]

From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Tue, 22 Jul 2014 20:20:04 -0300

> On 23 Jul 12:29 AM, Thomas Petazzoni wrote:
>> On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
>> 
>> > >> This series does not apply to the 'net' tree at all, please respin
>> > >> and resubmit.
>> > > 
>> > > This series applies on net-next.
>> > > 
>> > > Sorry for not mentioning it,
>> > 
>> > They are bonafide bug fixes, therefore should be targetted at 'net'.
>> 
>> Except that I believe they are fixes for a driver which itself is in
>> net-next, i.e scheduled for 3.17.
>> 
> 
> That's right. These are fixes for the new mvpp2 driver, which is only
> in net-next.

Ok, I queued them back up, thanks for the clarification.

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 22 Jul 2014 17:41:53 -0700 (PDT)

> From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date: Tue, 22 Jul 2014 20:20:04 -0300
> 
>> On 23 Jul 12:29 AM, Thomas Petazzoni wrote:
>>> On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
>>> 
>>> > >> This series does not apply to the 'net' tree at all, please respin
>>> > >> and resubmit.
>>> > > 
>>> > > This series applies on net-next.
>>> > > 
>>> > > Sorry for not mentioning it,
>>> > 
>>> > They are bonafide bug fixes, therefore should be targetted at 'net'.
>>> 
>>> Except that I believe they are fixes for a driver which itself is in
>>> net-next, i.e scheduled for 3.17.
>>> 
>> 
>> That's right. These are fixes for the new mvpp2 driver, which is only
>> in net-next.
> 
> Ok, I queued them back up, thanks for the clarification.

I've applied the 4 driver patches to net-next.  But, since the ARM
device tree file changes did not go into net-next, I can't apply the
last two patches to my tree.  You'll need to sort that out yourself.

It's a bit unfortunate that things are now out of sync like this, but
that's what you asked me to do.

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[Ezequiel Garcia]

On 22 Jul 07:52 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 22 Jul 2014 17:41:53 -0700 (PDT)
> 
> > From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> > Date: Tue, 22 Jul 2014 20:20:04 -0300
> > 
> >> On 23 Jul 12:29 AM, Thomas Petazzoni wrote:
> >>> On Tue, 22 Jul 2014 13:16:39 -0700 (PDT), David Miller wrote:
> >>> 
> >>> > >> This series does not apply to the 'net' tree at all, please respin
> >>> > >> and resubmit.
> >>> > > 
> >>> > > This series applies on net-next.
> >>> > > 
> >>> > > Sorry for not mentioning it,
> >>> > 
> >>> > They are bonafide bug fixes, therefore should be targetted at 'net'.
> >>> 
> >>> Except that I believe they are fixes for a driver which itself is in
> >>> net-next, i.e scheduled for 3.17.
> >>> 
> >> 
> >> That's right. These are fixes for the new mvpp2 driver, which is only
> >> in net-next.
> > 
> > Ok, I queued them back up, thanks for the clarification.
> 
> I've applied the 4 driver patches to net-next.  But, since the ARM
> device tree file changes did not go into net-next, I can't apply the
> last two patches to my tree.  You'll need to sort that out yourself.
> 
> It's a bit unfortunate that things are now out of sync like this, but
> that's what you asked me to do.

Thanks for applying this. We'll queue the devicetree changes as fixes
for v3.17-rc1 through the arm-soc tree.
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: [PATCH 0/6] net: mvpp2: Assorted fixes

[Jason Cooper]

On Mon, Jul 21, 2014 at 01:48:10PM -0300, Ezequiel Garcia wrote:
> This patchset contains a set of fixes for issues found while doing some
> more intensive tests on the recently accepted mvpp2 ethernet driver.
> 
> David: if we are still in time, we'd like to get the driver fixes merged
> for v3.17-rc1.
> 
> For the devicetree changes, it's already too late for that, since Jason
> Cooper has already posted the PRs for v3.17. I'll re-post them when
> v3.17-rc1 is released.
> 
> As usual, feedback is welcome.
> 
> Ezequiel Garcia (3):
>   net: mvpp2: Fix the BM pool buffer release check
>   net: mvpp2: Simplify BM pool buffers freeing
>   ARM: mvebu: Add missing MDIO clock in Armada 375
> 
> Marcin Wojtas (3):
>   net: mvpp2: Fix the periodic XON enable bit
>   net: mvpp2: Enable proper PHY polling and fix port functionality
>   ARM: mvebu: Add ethernet aliases required by U-Boot
> 
>  arch/arm/boot/dts/armada-375.dtsi    |  3 ++
>  drivers/net/ethernet/marvell/mvpp2.c | 65 +++++++++++++++++++++++-------------
>  2 files changed, 44 insertions(+), 24 deletions(-)

Patches 5 and 6 (dtsi changes) applied to mvebu/dt for v3.17

thx,

Jason.