@@ -0,0 +1,112 @@+Qualcomm Technologies EMAC Gigabit Ethernet Controller++This network controller consists of two devices: a MAC and an SGMII+internal PHY. Each device is represented by a device tree node. A phandle+connects the MAC node to its corresponding internal phy node. Another+phandle points to the external PHY node.++Required properties:++MAC node:+- compatible : Should be "qcom,fsm9900-emac".+- reg : Offset and length of the register regions for the device+- interrupts : Interrupt number used by this controller+- mac-address : The 6-byte MAC address. If present, it is the default+ MAC address.+- internal-phy : phandle to the internal PHY node+- phy-handle : phandle the the external PHY node++Internal PHY node:+- compatible : Should be "qcom,fsm9900-emac-sgmii" or "qcom,qdf2432-emac-sgmii".+- reg : Offset and length of the register region(s) for the device+- interrupts : Interrupt number used by this controller++The external phy child node:+- reg : The phy address++Example:++FSM9900:++soc {+ #address-cells = <1>;+ #size-cells = <1>;++ emac0: ethernet@feb20000 {+ compatible = "qcom,fsm9900-emac";+ reg = <0xfeb20000 0x10000>,+ <0xfeb36000 0x1000>;+ interrupts = <76>;++ clocks = <&gcc 0>, <&gcc 1>, <&gcc 3>, <&gcc 4>, <&gcc 5>,+ <&gcc 6>, <&gcc 7>;+ clock-names = "axi_clk", "cfg_ahb_clk", "high_speed_clk",+ "mdio_clk", "tx_clk", "rx_clk", "sys_clk";++ internal-phy = <&emac_sgmii>;
Can't this use the standard generic phy binding (i.e. 'phys'). It's a
bit confusing as there's the ethernet phy binding (phy-handle) and the
generic one.
+
+ phy-handle = <&phy0>;
This is bit redundant as the phy is the child node. I guess if you had
multiple devices on the mdio bus you would need it. I'd drop it if you
don't envision needing it and the kernel doesn't require it.
It's just an example, but don't we require compatible strings for phys
now?
+ reg = <0>;
+ };
+
--
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
From: Timur Tabi <hidden> Date: 2016-08-31 15:11:17
Rob Herring wrote:
quoted
+ internal-phy = <&emac_sgmii>;
Can't this use the standard generic phy binding (i.e. 'phys'). It's a
bit confusing as there's the ethernet phy binding (phy-handle) and the
generic one.
It's not a generic phy. It's a funky "internal phy" that differs among
SOCs. I call it the internal phy, but I could use another name.
Internally, some people call it the "sgmii phy", but I don't think
that's accurate.
I can call it "emac-phy", but I don't know if that's any better.
quoted
+ phy-handle = <&phy0>;
This is bit redundant as the phy is the child node. I guess if you had
multiple devices on the mdio bus you would need it. I'd drop it if you
don't envision needing it and the kernel doesn't require it.
That's what I thought to, but without it, of_phy_find_device() won't
work. I need a pointer to the phy node, and I use of_parse_phandle() to
get it:
struct device_node *phy_np;
ret = of_mdiobus_register(mii_bus, np);
if (ret) {
dev_err(&pdev->dev, "could not register mdio bus\n");
return ret;
}
phy_np = of_parse_phandle(np, "phy-handle", 0);
adpt->phydev = of_phy_find_device(phy_np);
It's just an example, but don't we require compatible strings for phys
now?
Nope. I had a compatible property, but it broke
of_mdiobus_child_is_phy(). I don't want to specify why kind of phy it
is. I want to let phylib figure it out.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
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
Can't this use the standard generic phy binding (i.e. 'phys'). It's a
bit confusing as there's the ethernet phy binding (phy-handle) and the
generic one.
Hi Rob
An ethernet PHY is much more complex than a generic PHY. The generic
phy API basically allows you to turn on/off or power up/down. An
Ethernet phy you can find out if there is anybody on the other end,
what speed is being used, set parameters used to negotiate what speed
to use, turn power saving features on off, find out if the other end
has power saving features, change the signal delays between the MAC
and the PHY, configure and handle interrupts when something changes,
configure WoL, etc.
If generic PHYs would of come first, things might be different, but
given that Ethernet PHYs are much much older and well entrenched into
device tree bindings, i don't see them merging.
quoted
+
+ phy-handle = <&phy0>;
This is bit redundant as the phy is the child node.
The Internal PHY is a child node. However, there is no reason an
external phy is a child. You sometimes see it connected to another
devices MDIO bus.
I guess if you had multiple devices on the mdio bus you would need
it.
And this is where people make errors. They hard code in the driver
that it should use the first phy on the bus. Then some hardware
engineer comes along and adds a second phy to the bus, and it
breaks. It is more robust to explicitly indicate which PHY is
connected to this MAC.
It's just an example, but don't we require compatible strings for phys
now?
We have never required compatibility strings for Ethernet PHYs. And
due to the stable binding rules, we now never can. The binding
documentation says it may contain compatible strings.
Andrew
From: Rob Herring <robh@kernel.org> Date: 2016-08-31 20:46:27
On Wed, Aug 31, 2016 at 10:11 AM, Timur Tabi [off-list ref] wrote:
Rob Herring wrote:
quoted
quoted
+ internal-phy = <&emac_sgmii>;
Can't this use the standard generic phy binding (i.e. 'phys'). It's a
bit confusing as there's the ethernet phy binding (phy-handle) and the
generic one.
It's not a generic phy. It's a funky "internal phy" that differs among
SOCs. I call it the internal phy, but I could use another name. Internally,
some people call it the "sgmii phy", but I don't think that's accurate.
Funky internal PHYs are precisely the types of PHYs this binding is
for. It is generic in that the type is not defined. It can be USB,
HDMI, DSI, LVDS, etc.
I can call it "emac-phy", but I don't know if that's any better.
quoted
quoted
+ phy-handle = <&phy0>;
This is bit redundant as the phy is the child node. I guess if you had
multiple devices on the mdio bus you would need it. I'd drop it if you
don't envision needing it and the kernel doesn't require it.
That's what I thought to, but without it, of_phy_find_device() won't work.
I need a pointer to the phy node, and I use of_parse_phandle() to get it:
struct device_node *phy_np;
ret = of_mdiobus_register(mii_bus, np);
if (ret) {
dev_err(&pdev->dev, "could not register mdio bus\n");
return ret;
}
phy_np = of_parse_phandle(np, "phy-handle", 0);
You can just as easily find the child node called ethernet-phy.
It's just an example, but don't we require compatible strings for phys
now?
Nope. I had a compatible property, but it broke of_mdiobus_child_is_phy().
I don't want to specify why kind of phy it is. I want to let phylib figure
it out.