On 01/21/2014 12:20 AM, Rob Herring wrote:

quoted

quoted

quoted

This patch is an attempt to gather the Ethernet related bindings in one
file,
like it's done in the MMC and some other subsystems. It should save the
trouble
of documenting several properties over and over in each binding document.

quoted

quoted

quoted

I have used the Embedded Power Architecture(TM) Platform Requirements
(ePAPR)
standard as a base for the properties description, also documenting some
ad-hoc
properties that have been introduced over time despite having direct
analogs in
ePAPR.

quoted

quoted

quoted

Signed-off-by: Sergei Shtylyov <redacted>

quoted

quoted

quoted

---
The patch is against DaveM's 'net-next.git' repo and the DaVinci EMAC
bindings
fix I've posted yesterday:

quoted

quoted

quoted

http://patchwork.ozlabs.org/patch/311854/

quoted

[...]

quoted

quoted

quoted

Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt
===================================================================

--- /dev/null
+++ net-next/Documentation/devicetree/bindings/net/ethernet.txt

@@ -0,0 +1,20 @@
+The following properties are common to the Ethernet controllers:
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that

was
+  assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last
used by
+  the boot program; should be used in cases where the MAC address
assigned to
+  the device by the boot program is different from the
"local-mac-address"
+  property;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the
device;
+- phy-mode: string, operation mode of the PHY interface; supported
values are
+  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+  "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii";

quoted

quoted

Mark this as deprecated

quoted

    That's kind of wishful thinking at this point, as that's what the
majority of drivers use. I'm unsure of the reasons why that was done,
probably people just didn't read the proper specs...

Or the spec was defined after those bindings.

    No, that's not likely as "phy-connection-type" prop seems very old, most 
probably predating ePAPR. ePAPR exists since 2008, kernel support for 
"phy-mode" prop dates back only to 2011.

Deprecating does not
matter for existing bindings. It's only defining new ones that are
affected. I was more concerned with giving people guidance on which
one to use for new bindings.

    If "phy-connection-type" is to be used, it makes sense to modify 
of_get_phy_mode() to also look for that prop, right?

quoted

quoted

in favor of phy-connection-type

quoted

    That one is only used by the oldish PowerPC 'gianfar' driver.

quoted

quoted

so it's use does not spread.

quoted

    I'm afraid that's too late, it has spread very far, so that
of_get_phy_mode() handles that property, not "phy-connection-type".

Uggg, I guess this is a case of a defacto standard then if the kernel
doesn't even support it.

    What's your guess on what to do on these 2 props then? Still deprecate 
"phy-mode"?

quoted

quoted

quoted

+- phy-connection-type: the same as "phy-mode" property (but described in
ePAPR);
+- phy-handle: phandle, specifies a reference to a node representing a
PHY
+  device (this property is described in ePAPR);
+- phy: the same as "phy-handle" property (but actually ad-hoc one).

quoted

quoted

Mark this as deprecated in favor of phy-handle.

quoted

    Here situation is more optimistic. Quite many drivers still use
"phy-handle", though some use even more exotic props I didn't document here.

Perhaps flagging as "Not recommended for new bindings" would be nicer wording...

    Perhaps.

Rob

WBR, Sergei