netdev - Re: [PATCH 7/7] Documentation: devicetree: add ar8xxx binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5567C915.5090808@gmail.com>
Date:	Thu, 28 May 2015 19:04:05 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Mathieu Olivari <mathieu@...eaurora.org>, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	davem@...emloft.net, andrew@...n.ch, linux@...ck-us.net,
	gang.chen.5i5j@...il.com, jiri@...nulli.us, leitec@...ticky.com,
	fabf@...net.be, alexander.h.duyck@...el.com,
	pavel.nakonechny@...tlab.ru, joe@...ches.com, sfeldma@...il.com,
	nbd@...nwrt.org, juhosg@...nwrt.org
CC:	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 7/7] Documentation: devicetree: add ar8xxx binding

Le 05/28/15 18:42, Mathieu Olivari a écrit :
> Add device-tree binding for ar8xxx switch families.
> 
> Signed-off-by: Mathieu Olivari <mathieu@...eaurora.org>
> ---
>  .../devicetree/bindings/net/dsa/qca-ar8xxx.txt     | 70 ++++++++++++++++++++++
>  1 file changed, 70 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt b/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
> new file mode 100644
> index 0000000..f4fd3f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/qca-ar8xxx.txt
> @@ -0,0 +1,70 @@
> +* Qualcomm Atheros AR8xxx switch family
> +
> +Required properties:
> +
> +- compatible: should be "qca,ar8xxx"
> +- dsa,mii-bus: phandle to the MDIO bus controller, see dsa/dsa.txt
> +- dsa,ethernet: phandle to the CPU network interface controller, see dsa/dsa.txt
> +- #size-cells: must be 0
> +- #address-cells: must be 2, see dsa/dsa.txt
> +
> +Subnodes:
> +
> +The integrated switch subnode should be specified according to the binding
> +described in dsa/dsa.txt.
> +
> +Optional properties:
> +
> +- qca,port6-phy-mode: if specified, the driver will configure Port 6 in the
> +  given phy-mode. See Documentation/devicetree/bindings/net/ethernet.txt for
> +  the list of valid phy-mode.

Is there a reason why this is a custom property and not a standard
"phy-mode" property here such that you could utilize of_get_phy_mode()
with this directly?

> +
> +- qca,port6-phy-id: if specified, the driver will connect Port 6 to the PHY
> +  given as a parameter. In this case, Port6 and the corresponding PHY will be
> +  isolated from the rest of the switch. From a system perspective, they will
> +  act as a regular PHY.

Same here, is there a reason why this is not a "phy-handle" property to
a PHY node that sits on a (potentially different) MDIO bus?

> +
> +Example:
> +
> +	dsa@0 {
> +		compatible = "qca,ar8xxx";
> +		#address-cells = <2>;
> +		#size-cells = <0>;
> +
> +		dsa,ethernet = <&ethernet0>;
> +		dsa,mii-bus = <&mii_bus0>;
> +
> +		switch@0 {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			reg = <0 0>;	/* MDIO address 0, switch 0 in tree */
> +
> +			qca,port6-phy-mode = "sgmii";
> +			qca,port6-phy-id = <4>;
> +
> +			port@0 {
> +				reg = <11>;
> +				label = "cpu";
> +			};
> +
> +			port@1 {
> +				reg = <0>;
> +				label = "lan1";
> +			};
> +
> +			port@2 {
> +				reg = <1>;
> +				label = "lan2";
> +			};
> +
> +			port@3 {
> +				reg = <2>;
> +				label = "lan3";
> +			};
> +
> +			port@4 {
> +				reg = <3>;
> +				label = "lan4";
> +			};
> +		};
> +	};
> 


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