Re: [PATCHv4 0/5] Add DT support for fixed PHYs
From: Florian Fainelli <hidden>
Date: 2014-05-16 18:27:36
Hi Thomas, 2014-05-16 7:14 GMT-07:00 Thomas Petazzoni [off-list ref]:
Subject: Add DT support for fixed PHYs Hello, Here is a fourth version of the patch set that adds a Device Tree binding and the related code to support fixed PHYs. I'm hoping to get this merged in 3.16.
Thanks for being persistent on this and coming back with these patches, that is really appreciated. I gave this patch set a try on a brcmstb system with SYSTEMPORT and my latest changes to net/dsa/ to allow for different PHY setups to be used with the SoC integrated switch. This switch has a mix of fixed and real PHYs. This works like a charm, so long as you consistently use the "new" functions, and not the old ones, which is totally expected. This is excellent work! As we discussed offline, I think we need to progressively get rid of of_phy_connect_fixed() to avoid having to debug situations where the old 'fixed-link' property used some sparse addressing scheme, which is now incompatible with the dynamic address allocation scheme.
Changes since v3:
* Rebased on top of v3.15-rc5
* In patch "net: phy: decouple PHY id and PHY address in fixed PHY
driver", changed the PHY ID of fixed PHYs from 0xdeadbeef to 0x0,
as suggested by Grant Likely.
* Fixed the !CONFIG_PHY_FIXED case in patch "net: phy: extend fixed
driver with fixed_phy_register()". Noticed by Florian Fainelli.
* Added Acked-by from Grant Likely and Florian Fainelli on patch
"net: phy: extend fixed driver with fixed_phy_register()".
* Reworked the new fixed-link DT binding to be just a sub-node of the
Ethernet MAC node, and not a node referenced by the 'phy'
property. This was requested by Grant Likely.
* Reworked the code implementing the new DT binding to also make it
accept the old, single property based, DT binding.
* Added a patch that actually uses the new fixed link DT binding for
the Armada XP Matrix board.
Changes since v2:
* Rebased on top of v3.14-rc1, and re-tested on hardware.
* Removed the RFC tag, since there seems to be some real interest in
this feature, and the code has gone through several iterations
already.
* The error handling in fixed_phy_register() has been fixed.
Changes since v1:
* Instead of using a 'fixed-link' property inside the Ethernet device
DT node, with a fairly cryptic succession of integer values, we now
use a PHY subnode under the Ethernet device DT node, with explicit
properties to configure the duplex, speed, pause and other PHY
properties.
* The PHY address is automatically allocated by the kernel and no
longer visible in the Device Tree binding.
* The PHY device is created directly when the network driver calls
of_phy_connect_fixed_link(), and associated to the PHY DT node,
which allows the existing of_phy_connect() function to work,
without the need to use the deprecated of_phy_connect_fixed_link().
Posts of previous versions:
RFCv1: http://www.spinics.net/lists/netdev/msg243253.html
RFCv2: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/196919.html
PATCHv3: http://www.spinics.net/lists/netdev/msg273117.html
Thanks,
Thomas
Thomas Petazzoni (5):
net: phy: decouple PHY id and PHY address in fixed PHY driver
net: phy: extend fixed driver with fixed_phy_register()
of: provide a binding for fixed link PHYs
net: mvneta: add support for fixed links
ARM: mvebu: use the fixed-link PHY DT binding for the Armada XP Matrix
board
.../devicetree/bindings/net/fixed-link.txt | 31 +++++++++
arch/arm/boot/dts/armada-xp-matrix.dts | 4 ++
drivers/net/ethernet/marvell/mvneta.c | 19 ++++-
drivers/net/phy/fixed.c | 81 +++++++++++++++++++---
drivers/of/of_mdio.c | 67 ++++++++++++++++++
include/linux/of_mdio.h | 15 ++++
include/linux/phy_fixed.h | 11 +++
7 files changed, 215 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
--
1.9.3-- Florian -- 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