On 3/26/19 4:24 AM, Florian Fainelli wrote:

On 3/23/2019 8:23 PM, Vladimir Oltean wrote:

quoted

Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
---
  .../devicetree/bindings/net/dsa/sja1105.txt   | 123 ++++++++++++++++++
  1 file changed, 123 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/net/dsa/sja1105.txt

diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt
new file mode 100644
index 000000000000..2c82b6fc37e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/sja1105.txt

@@ -0,0 +1,123 @@
+NXP SJA1105 switch driver
+=========================
+
+Required properties:
+
+- compatible: Must be "nxp,sja1105". Device ID identification (one of
+  E/T/P/Q/R/S) is performed by driver at probe time. Swapping pin-compatible
+  parts is possible with no DTS change.
+
+Optional properties:
+
+- sja1105,mac-mode, sja1105,phy-mode: Boolean properties that can be assigned
+  under each port node that is MII or RMII (has no effect for RGMII).  By
+  default (unless otherwise specified) a port is configured as MAC if it is
+  driving a PHY (phy-handle is present) or as PHY if it is PHY-less (fixed-link
+  specified, presumably because it is connected to a MAC).  These properties
+  are required in the case where SJA1105 ports are at both ends of an MII/RMII
+  PHY-less setup. One end would need to have sja1105,mac-mode, while the other
+  sja1105,phy-mode.

Typically we would be using a fixed-link with an appropriate 'phy-mode'
property to describe a MAC to MAC connection, this may be seen as a
re-purposing PHY-oriented properties though, so I am fine with that binding:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>

Hi Florian,

I don't feel amazing about my solution either, but I don't think I'm 
understanding what you propose. Something like phy-mode = "rmii-mac" or 
"rmii-phy" or "mii-mac" or "mii-phy"?
Would that require an update of the phy_modes() function and strings?
I think the last time when an interface type was split into further 
subdivisions (RGMII with all its internal delay flavors) it didn't go 
too well - with lots of bugs introduced simply because drivers failed to 
grok the newly introduced subtypes as still being RGMII.

Thank you,
-Vladimir