[PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Sebastian Hesselbarth]

This patch series deals with a removing a IP feature that can be found
on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
without software interaction.

However, this feature (a) fundamentally clashes with the way libphy works
and (b) is unable to deal with quirky PHYs that require special treatment.
In this series, pxa168_eth driver is rewritten to completely disable that
feature and properly deal with libphy provided PHYs. The other two drivers
are suspect to future patch sets, also removing the code related with it.

Currently, the patches are based on next-20141009 and will be resent once
v3.18-rc1 drops. This is a Request-For-Test on both BG2Q and MMP/gplug as
these are the current users of pxa168_eth. A branch with this patches on
top of next-20141009 can be found at

git://git.infradead.org/users/hesselba/linux-berlin.git devel/bg2-bg2cd-eth-v1

It would be great to get a Tested-byfrom MMP guys on gplug - if they
have that board somewhere. Also, BG2Q (Antoine) needs a phy-connection-type
property. My guess is that, if it is using internal PHY, it is "mii", too.

Patch 1 adds support for Marvell 88E3016 FastEthernet PHY that is also
integrated in Marvell Berlin BG2/BG2CD SoCs.

Patch 2 allows to pass phy_interface_t on pxa168_eth platform_data that
is only used by mach-mmp/gplug. From the board setup, I guessed gplug's
PHY is connected via RMII. The patch isn't even compile tested, so here
I need a Tested-by from MMP guys.

Patches 3-5 prepare proper libphy handling and finally remove all in-driver
PHY mangling related to the feature explained above.

Patches 6-8 add corresponding ethernet DT nodes to BG2, BG2CD, and
BG2-based Sony NSZ-GS7. I have tested all this on GS7 successfully with
ip=dhcp on 100M FD.

Sebastian Hesselbarth (8):
  phy: marvell: Add support for 88E3016 FastEthernet PHY
  net: pxa168_eth: Provide phy_interface mode on platform_data
  net: pxa168_eth: Prepare proper libphy handling
  net: pxa168_eth: Remove HW auto-negotiaion
  net: pxa168_eth: Remove in-driver PHY mangling
  ARM: berlin: Add BG2 ethernet DT nodes
  ARM: berlin: Add BG2CD ethernet DT nodes
  ARM: berlin: Enable ethernet on Sony NSZ-GS7

 arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts |   2 +
 arch/arm/boot/dts/berlin2.dtsi             |  36 +++++
 arch/arm/boot/dts/berlin2cd.dtsi           |  36 +++++
 arch/arm/mach-mmp/gplugd.c                 |   2 +
 drivers/net/ethernet/marvell/pxa168_eth.c  | 242 +++++++++++------------------
 drivers/net/phy/marvell.c                  |  46 ++++++
 include/linux/marvell_phy.h                |   1 +
 include/linux/pxa168_eth.h                 |   1 +
 8 files changed, 218 insertions(+), 148 deletions(-)

---
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: "Antoine Ténart" <antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Eric Miao <eric.y.miao-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Haojian Zhuang <haojian.zhuang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
-- 
2.1.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFT 6/8] ARM: berlin: Add BG2 ethernet DT nodes

[Sebastian Hesselbarth]

Marvell BG2 has two fast ethernet controllers with internal PHY,
add the corresponding nodes to SoC dtsi.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/berlin2.dtsi | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index d7e81e124de0..5f82dcfc6ac6 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -79,11 +79,47 @@
 			clocks = <&chip CLKID_TWD>;
 		};
 
+		eth1: ethernet@b90000 {
+			compatible = "marvell,pxa168-eth";
+			reg = <0xb90000 0x10000>;
+			clocks = <&chip CLKID_GETH1>;
+			interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+			/* set by bootloader */
+			local-mac-address = [00 00 00 00 00 00];
+			#address-cells = <1>;
+			#size-cells = <0>;
+			phy-handle = <&ethphy1>;
+			status = "disabled";
+
+			ethphy1: ethernet-phy@0 {
+				phy-connection-type = "mii";
+				reg = <0>;
+			};
+		};
+
 		cpu-ctrl@dd0000 {
 			compatible = "marvell,berlin-cpu-ctrl";
 			reg = <0xdd0000 0x10000>;
 		};
 
+		eth0: ethernet@e50000 {
+			compatible = "marvell,pxa168-eth";
+			reg = <0xe50000 0x10000>;
+			clocks = <&chip CLKID_GETH0>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			/* set by bootloader */
+			local-mac-address = [00 00 00 00 00 00];
+			#address-cells = <1>;
+			#size-cells = <0>;
+			phy-handle = <&ethphy0>;
+			status = "disabled";
+
+			ethphy0: ethernet-phy@0 {
+				phy-connection-type = "mii";
+				reg = <0>;
+			};
+		};
+
 		apb@e80000 {
 			compatible = "simple-bus";
 			#address-cells = <1>;
-- 
2.1.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH RFT 7/8] ARM: berlin: Add BG2CD ethernet DT nodes

[Sebastian Hesselbarth]

Marvell BG2CD has two fast ethernet controllers with internal PHY,
add the corresponding nodes to SoC dtsi.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/berlin2cd.dtsi | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 68f7032b4686..ee3a22ad4b5f 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -66,6 +66,42 @@
 			clocks = <&chip CLKID_TWD>;
 		};
 
+		eth1: ethernet@b90000 {
+			compatible = "marvell,pxa168-eth";
+			reg = <0xb90000 0x10000>;
+			clocks = <&chip CLKID_GETH1>;
+			interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+			/* set by bootloader */
+			local-mac-address = [00 00 00 00 00 00];
+			#address-cells = <1>;
+			#size-cells = <0>;
+			phy-handle = <&ethphy1>;
+			status = "disabled";
+
+			ethphy1: ethernet-phy@0 {
+				phy-connection-type = "mii";
+				reg = <0>;
+			};
+		};
+
+		eth0: ethernet@e50000 {
+			compatible = "marvell,pxa168-eth";
+			reg = <0xe50000 0x10000>;
+			clocks = <&chip CLKID_GETH0>;
+			interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+			/* set by bootloader */
+			local-mac-address = [00 00 00 00 00 00];
+			#address-cells = <1>;
+			#size-cells = <0>;
+			phy-handle = <&ethphy0>;
+			status = "disabled";
+
+			ethphy0: ethernet-phy@0 {
+				phy-connection-type = "mii";
+				reg = <0>;
+			};
+		};
+
 		apb@e80000 {
 			compatible = "simple-bus";
 			#address-cells = <1>;
-- 
2.1.1

[PATCH RFT 8/8] ARM: berlin: Enable ethernet on Sony NSZ-GS7

[Sebastian Hesselbarth]

Marvell Berlin BG2 based Sony NSZ-GS7 has one ethernet controller
connected to rear RJ45 jack. Enable it by default.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
index c72bfd468d10..27f2f0ad7562 100644
--- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
+++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
@@ -26,4 +26,6 @@
 	};
 };
 
+&eth1 { status = "okay"; };
+
 &uart0 { status = "okay"; };
-- 
2.1.1

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Thu,  9 Oct 2014 14:38:58 +0200, Sebastian Hesselbarth wrote:

> This patch series deals with a removing a IP feature that can be found
> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
> without software interaction.
> 
> However, this feature (a) fundamentally clashes with the way libphy works
> and (b) is unable to deal with quirky PHYs that require special treatment.
> In this series, pxa168_eth driver is rewritten to completely disable that
> feature and properly deal with libphy provided PHYs. The other two drivers
> are suspect to future patch sets, also removing the code related with it.

Hum, in mvneta, we already disabled the automatic negotiation and use
libphy. What makes you think the current mvneta driver is wrong in this
respect?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Sebastian Hesselbarth]

On 10/09/2014 04:33 PM, Thomas Petazzoni wrote:
> Dear Sebastian Hesselbarth,
>
> On Thu,  9 Oct 2014 14:38:58 +0200, Sebastian Hesselbarth wrote:
>
>> This patch series deals with a removing a IP feature that can be found
>> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
>> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
>> without software interaction.
>>
>> However, this feature (a) fundamentally clashes with the way libphy works
>> and (b) is unable to deal with quirky PHYs that require special treatment.
>> In this series, pxa168_eth driver is rewritten to completely disable that
>> feature and properly deal with libphy provided PHYs. The other two drivers
>> are suspect to future patch sets, also removing the code related with it.
>
> Hum, in mvneta, we already disabled the automatic negotiation and use
> libphy. What makes you think the current mvneta driver is wrong in this
> respect?

I didn't check mvneta, but remember Ezequiel didn't clear all AN bits
in the barebox driver (which is based on Linux mvneta). Just mentioned
that I'll have a closer look at it.

But I agree, regarding libphy support mvneta is probably the best
already.

Sebastian

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Thu, 09 Oct 2014 16:41:48 +0200, Sebastian Hesselbarth wrote:

> > Hum, in mvneta, we already disabled the automatic negotiation and use
> > libphy. What makes you think the current mvneta driver is wrong in this
> > respect?
> 
> I didn't check mvneta, but remember Ezequiel didn't clear all AN bits
> in the barebox driver (which is based on Linux mvneta). Just mentioned
> that I'll have a closer look at it.

Ah, ok.

> But I agree, regarding libphy support mvneta is probably the best
> already.

Well, I initially remember that the original driver coming from Marvell
was using the HW PHY stuff, and that I changed that because it would
not integrate well with the kernel libphy.

A drawback of this is that because the hardware has built-in PHY
polling which triggers a MAC interrupt when the PHY status changes, they
typically don't wire up the PHY interrupt. Therefore, since we're not
able to use the MAC interrupt for PHY event notifications, we rely on
software PHY polling, which means that link up / link down events take
a few seconds to be noticed by the kernel. Unfortunately, I don't think
the hardware allows to use the hardware PHY polling to get link changes
interrupt, but not let the hardware configure the PHY itself.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Sebastian Hesselbarth]

On 10/09/2014 04:47 PM, Thomas Petazzoni wrote:
> Well, I initially remember that the original driver coming from Marvell
> was using the HW PHY stuff, and that I changed that because it would
> not integrate well with the kernel libphy.
>
> A drawback of this is that because the hardware has built-in PHY
> polling which triggers a MAC interrupt when the PHY status changes, they
> typically don't wire up the PHY interrupt. Therefore, since we're not
> able to use the MAC interrupt for PHY event notifications, we rely on
> software PHY polling, which means that link up / link down events take
> a few seconds to be noticed by the kernel. Unfortunately, I don't think
> the hardware allows to use the hardware PHY polling to get link changes
> interrupt, but not let the hardware configure the PHY itself.

Yeah, but that HW PHY stuff really only works properly with standard
compliant PHYs. In particular, the integrated Marvell PHY in Marvell
Berlin SoCs does not seem to reflect PHY status on BMCR properly /sigh/.
Anyway, I think we can live with PHY polling.

BTW, one thing I noticed here is that libphy calls adjust_link
over-and-over again although nothing has changed. I guess we can just
add some before/after comparison in the libphy state machine and only
call adjust_link when something has changed. I'll have to look closer
at the state machine first and maybe Florian can comment on this,
too.

Sebastian

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Florian Fainelli]

On 10/09/2014 08:24 AM, Sebastian Hesselbarth wrote:
> On 10/09/2014 04:47 PM, Thomas Petazzoni wrote:
>> Well, I initially remember that the original driver coming from Marvell
>> was using the HW PHY stuff, and that I changed that because it would
>> not integrate well with the kernel libphy.
>>
>> A drawback of this is that because the hardware has built-in PHY
>> polling which triggers a MAC interrupt when the PHY status changes, they
>> typically don't wire up the PHY interrupt. Therefore, since we're not
>> able to use the MAC interrupt for PHY event notifications, we rely on
>> software PHY polling, which means that link up / link down events take
>> a few seconds to be noticed by the kernel. Unfortunately, I don't think
>> the hardware allows to use the hardware PHY polling to get link changes
>> interrupt, but not let the hardware configure the PHY itself.
> 
> Yeah, but that HW PHY stuff really only works properly with standard
> compliant PHYs. In particular, the integrated Marvell PHY in Marvell
> Berlin SoCs does not seem to reflect PHY status on BMCR properly /sigh/.
> Anyway, I think we can live with PHY polling.
> 
> BTW, one thing I noticed here is that libphy calls adjust_link
> over-and-over again although nothing has changed. I guess we can just
> add some before/after comparison in the libphy state machine and only
> call adjust_link when something has changed. I'll have to look closer
> at the state machine first and maybe Florian can comment on this,
> too.

There's basically nothing built in the generic libphy that would try to
limit the number of times the adjust_link() callback is invoked, some
changes went in the bcmgenet driver to avoid that, I have yet to see how
much of this logic is transferable to the libphy layer.
--
Florian

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Sebastian Hesselbarth]

On 10/09/2014 06:57 PM, Florian Fainelli wrote:
> On 10/09/2014 08:24 AM, Sebastian Hesselbarth wrote:
>> Yeah, but that HW PHY stuff really only works properly with standard
>> compliant PHYs. In particular, the integrated Marvell PHY in Marvell
>> Berlin SoCs does not seem to reflect PHY status on BMCR properly /sigh/.
>> Anyway, I think we can live with PHY polling.
>>
>> BTW, one thing I noticed here is that libphy calls adjust_link
>> over-and-over again although nothing has changed. I guess we can just
>> add some before/after comparison in the libphy state machine and only
>> call adjust_link when something has changed. I'll have to look closer
>> at the state machine first and maybe Florian can comment on this,
>> too.
>
> There's basically nothing built in the generic libphy that would try to
> limit the number of times the adjust_link() callback is invoked, some
> changes went in the bcmgenet driver to avoid that, I have yet to see how
> much of this logic is transferable to the libphy layer.

Ok, thanks for the clarification. I guess for the final patch series,
I'll add a check for both registers modified in foo_adjust_link to bail
out if there is no change. That will save the two register writes per
second or so and also allow to phy_print_status() after the writels.

Sebastian

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Antoine Tenart]

Hi Sebastian,

On Thu, Oct 09, 2014 at 02:38:58PM +0200, Sebastian Hesselbarth wrote:
> This patch series deals with a removing a IP feature that can be found
> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
> without software interaction.
> 
> However, this feature (a) fundamentally clashes with the way libphy works
> and (b) is unable to deal with quirky PHYs that require special treatment.
> In this series, pxa168_eth driver is rewritten to completely disable that
> feature and properly deal with libphy provided PHYs. The other two drivers
> are suspect to future patch sets, also removing the code related with it.
> 
> Currently, the patches are based on next-20141009 and will be resent once
> v3.18-rc1 drops. This is a Request-For-Test on both BG2Q and MMP/gplug as

I tested the series on a BG2Q, it worked well.

Antoine

> these are the current users of pxa168_eth. A branch with this patches on
> top of next-20141009 can be found at
> 
> git://git.infradead.org/users/hesselba/linux-berlin.git devel/bg2-bg2cd-eth-v1
> 
> It would be great to get a Tested-byfrom MMP guys on gplug - if they
> have that board somewhere. Also, BG2Q (Antoine) needs a phy-connection-type
> property. My guess is that, if it is using internal PHY, it is "mii", too.

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Sebastian Hesselbarth]

On 16.10.2014 11:53, Antoine Tenart wrote:
> On Thu, Oct 09, 2014 at 02:38:58PM +0200, Sebastian Hesselbarth wrote:
>> This patch series deals with a removing a IP feature that can be found
>> on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
>> mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
>> without software interaction.
>>
>> However, this feature (a) fundamentally clashes with the way libphy works
>> and (b) is unable to deal with quirky PHYs that require special treatment.
>> In this series, pxa168_eth driver is rewritten to completely disable that
>> feature and properly deal with libphy provided PHYs. The other two drivers
>> are suspect to future patch sets, also removing the code related with it.
>>
>> Currently, the patches are based on next-20141009 and will be resent once
>> v3.18-rc1 drops. This is a Request-For-Test on both BG2Q and MMP/gplug as
>
> I tested the series on a BG2Q, it worked well.

Antoine,

Thanks for testing! I assume you have added a phy-connection-type
property to BG2Q's ethernet node?

I doubt there will be any Tested-by from MMP guys anytime soon, so
I'll resend this with the minor remarks to be merged for 3.19.

Sebastian

Re: [PATCH RFT 0/8] Marvell PXA168 libphy handling and Berlin Ethernet

[Antoine Tenart]

Sebastian,

On Mon, Oct 20, 2014 at 04:37:51PM +0200, Sebastian Hesselbarth wrote:
> On 16.10.2014 11:53, Antoine Tenart wrote:
> >On Thu, Oct 09, 2014 at 02:38:58PM +0200, Sebastian Hesselbarth wrote:
> >>This patch series deals with a removing a IP feature that can be found
> >>on all currently supported Marvell Ethernet IP (pxa168_eth, mv643xx_eth,
> >>mvneta). The MAC IP allows to automatically perform PHY auto-negotiation
> >>without software interaction.
> >>
> >>However, this feature (a) fundamentally clashes with the way libphy works
> >>and (b) is unable to deal with quirky PHYs that require special treatment.
> >>In this series, pxa168_eth driver is rewritten to completely disable that
> >>feature and properly deal with libphy provided PHYs. The other two drivers
> >>are suspect to future patch sets, also removing the code related with it.
> >>
> >>Currently, the patches are based on next-20141009 and will be resent once
> >>v3.18-rc1 drops. This is a Request-For-Test on both BG2Q and MMP/gplug as
> >
> >I tested the series on a BG2Q, it worked well.
> 
> Thanks for testing! I assume you have added a phy-connection-type
> property to BG2Q's ethernet node?

Yes, I added the following property to the ethernet-phy node:

	phy-connection-type = "mii";

Feel free to add this to your series, or I can also send a patch.


Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com