Re: [PATCH v7 net-next 06/13] dt-bindings: net: ti: add new cpsw switch driver bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob,

On 21/11/2019 21:24, Rob Herring wrote:
On Tue, Nov 19, 2019 at 4:19 PM Grygorii Strashko
<grygorii.strashko@xxxxxx> wrote:

Add bindings for the new TI CPSW switch driver. Comparing to the legacy
bindings (net/cpsw.txt):
- ports definition follows DSA bindings (net/dsa/dsa.txt) and ports can be
marked as "disabled" if not physically wired.
- all deprecated properties dropped;
- all legacy propertiies dropped which represent constant HW cpapbilities
(cpdma_channels, ale_entries, bd_ram_size, mac_control, slaves,
active_slave)
- TI CPTS DT properties are reused as is, but grouped in "cpts" sub-node
- TI Davinci MDIO DT bindings are reused as is, because Davinci MDIO is
reused.

Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx>
---
  .../bindings/net/ti,cpsw-switch.yaml          | 240 ++++++++++++++++++
  1 file changed, 240 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml

I see David has applied this already, but it still has numerous
problems. Please send a follow-up.


diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
new file mode 100644
index 000000000000..81ae8cafabc1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml
@@ -0,0 +1,240 @@
+# SPDX-License-Identifier: GPL-2.0

For new bindings, please dual license:

(GPL-2.0-only OR BSD-2-Clause)

+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/ti,cpsw-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI SoC Ethernet Switch Controller (CPSW) Device Tree Bindings
+
+maintainers:
+  - Grygorii Strashko <grygorii.strashko@xxxxxx>
+  - Sekhar Nori <nsekhar@xxxxxx>
+
+description:
+  The 3-port switch gigabit ethernet subsystem provides ethernet packet
+  communication and can be configured as an ethernet switch. It provides the
+  gigabit media independent interface (GMII),reduced gigabit media
+  independent interface (RGMII), reduced media independent interface (RMII),
+  the management data input output (MDIO) for physical layer device (PHY)
+  management.
+
+properties:
+  compatible:
+    oneOf:
+      - const: ti,cpsw-switch
+      - items:
+         - const: ti,am335x-cpsw-switch
+         - const: ti,cpsw-switch
+      - items:
+        - const: ti,am4372-cpsw-switch
+        - const: ti,cpsw-switch
+      - items:
+        - const: ti,dra7-cpsw-switch
+        - const: ti,cpsw-switch
+
+  reg:
+    maxItems: 1
+    description:
+       The physical base address and size of full the CPSW module IO range
+
+  ranges: true
+
+  clocks:
+    maxItems: 1
+    description: CPSW functional clock
+
+  clock-names:
+    maxItems: 1
+    items:
+      - const: fck
+
+  interrupts:
+    items:
+      - description: RX_THRESH interrupt
+      - description: RX interrupt
+      - description: TX interrupt
+      - description: MISC interrupt
+
+  interrupt-names:
+    items:
+      - const: "rx_thresh"
+      - const: "rx"
+      - const: "tx"
+      - const: "misc"
+
+  pinctrl-names: true
+
+  syscon:
+    $ref: /schemas/types.yaml#definitions/phandle
+    description:
+      Phandle to the system control device node which provides access to
+      efuse IO range with MAC addresses

Can't you use nvmem binding for this?

I've sent patch to fix other comments except this one.

About nvmem,I've been thinking about it for a long time already, but in our case
MAC address is encoded in eFuse register in a different way for different SoCs.

So even if I'll try to use nvmem and define some MAC cell:

	efuse: efuse {
		compatible = "...";
		#address-cells = <1>;
		#size-cells = <1>;

		eth_mac: eth_mac@34 {
			reg = <0x34 0x10>;
		};
	};

	portX {
		...
		nvmem-cells = <&eth_mac>;
		nvmem-cell-names = "mac-address";
	};

the of_get_mac_address() will finally call
  nvmem->reg_read(priv, offset, val, bytes);

and at this point nvmem driver will have no knowledge about the type of the cell
(MAC address), so no decoding can not be done and returned mac will be incorrect.

Not sure how to proceed here. One of the ways is to pass cell info in
struct nvmem_device .reg_read()/.reg_write() callbacks, cell name could be use
to perform some actions.

Another thing which need to be considered is - MAC can be assigned per port,
so dev->of_node != port_of_node (and of_get_mac_addr_nvmem() will fail).



--
Best regards,
grygorii



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux