diff mbox series

[net-next,v2,08/15] dt-bindings: net: dsa: qca8k: Add MAC swap and clock phase properties

Message ID 20211008002225.2426-9-ansuelsmth@gmail.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series Multiple improvement for qca8337 switch | expand

Checks

Context Check Description
netdev/cover_letter success Series has a cover letter
netdev/fixes_present success Fixes tag not required for -next series
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers success CCed 9 of 9 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success No Fixes tag
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 11 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success No static functions without inline keyword in header files

Commit Message

Christian Marangi Oct. 8, 2021, 12:22 a.m. UTC
Add names and decriptions of additional PORT0_PAD_CTRL properties.
Document new binding qca,mac6_exchange that exchange the mac0 port
with mac6.
qca,sgmii-(rx|tx)clk-falling-edge are for setting the respective clock
phase to failling edge.

Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
---
 Documentation/devicetree/bindings/net/dsa/qca8k.txt | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Andrew Lunn Oct. 9, 2021, 5:07 p.m. UTC | #1
On Fri, Oct 08, 2021 at 02:22:18AM +0200, Ansuel Smith wrote:
> Add names and decriptions of additional PORT0_PAD_CTRL properties.
> Document new binding qca,mac6_exchange that exchange the mac0 port
> with mac6.
> qca,sgmii-(rx|tx)clk-falling-edge are for setting the respective clock
> phase to failling edge.
> 
> Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
>  Documentation/devicetree/bindings/net/dsa/qca8k.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> index 9383d6bf2426..208ee5bc1bbb 100644
> --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> @@ -13,6 +13,11 @@ Required properties:
>  Optional properties:
>  
>  - reset-gpios: GPIO to be used to reset the whole device
> +- qca,mac6-exchange: Internally swap MAC0 with MAC6.
> +- qca,sgmii-rxclk-falling-edge: Set the receive clock phase to falling edge.
> +                                Mostly used in qca8327 with CPU port 0 set to
> +                                sgmii.
> +- qca,sgmii-txclk-falling-edge: Set the transmit clock phase to falling edge.
>  - qca,rgmii0-1-8v: Set the internal regulator to supply 1.8v for MAC0 port.
>                     This is needed for qca8337 and toggles the supply voltage
>                     from 1.5v to 1.8v. For the specific regs it was observed

The edge configuration is a port configuration. So it should be inside
the port DT node it applies to. That also gives a clean way forward
when a new switch appears with more SGMII interfaces, each with its
own edge configuration.

But that then leads into the MAC0/MAC6 swap mess. I need to think
about that some more, how do we cleanly describe that in DT.

      Andrew
Christian Marangi Oct. 9, 2021, 6:08 p.m. UTC | #2
On Sat, Oct 09, 2021 at 07:07:16PM +0200, Andrew Lunn wrote:
> On Fri, Oct 08, 2021 at 02:22:18AM +0200, Ansuel Smith wrote:
> > Add names and decriptions of additional PORT0_PAD_CTRL properties.
> > Document new binding qca,mac6_exchange that exchange the mac0 port
> > with mac6.
> > qca,sgmii-(rx|tx)clk-falling-edge are for setting the respective clock
> > phase to failling edge.
> > 
> > Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/net/dsa/qca8k.txt | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> > index 9383d6bf2426..208ee5bc1bbb 100644
> > --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> > +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
> > @@ -13,6 +13,11 @@ Required properties:
> >  Optional properties:
> >  
> >  - reset-gpios: GPIO to be used to reset the whole device
> > +- qca,mac6-exchange: Internally swap MAC0 with MAC6.
> > +- qca,sgmii-rxclk-falling-edge: Set the receive clock phase to falling edge.
> > +                                Mostly used in qca8327 with CPU port 0 set to
> > +                                sgmii.
> > +- qca,sgmii-txclk-falling-edge: Set the transmit clock phase to falling edge.
> >  - qca,rgmii0-1-8v: Set the internal regulator to supply 1.8v for MAC0 port.
> >                     This is needed for qca8337 and toggles the supply voltage
> >                     from 1.5v to 1.8v. For the specific regs it was observed
> 
> The edge configuration is a port configuration. So it should be inside
> the port DT node it applies to. That also gives a clean way forward
> when a new switch appears with more SGMII interfaces, each with its
> own edge configuration.
> 

Problem here is that from Documentation falling edge can be set only on
PAD0. PAD5 and PAD6 have the related bit reserved.
But anyway qca8k support only single sgmii and it's not supported a
config with multiple sgmii. Do we have standard binding for this?

> But that then leads into the MAC0/MAC6 swap mess. I need to think
> about that some more, how do we cleanly describe that in DT.
> 
>       Andrew

About the mac swap. Do we really need to implement a complex thing for
something that is really implemented internally to the switch? With this
option MAC6 is swapped with MAC0. But with the port configuration in DT
it doesn't change anything. Same reg, no change. It's really that some
OEM connect the secondary port instead of the primary (for some reason,
hw choice?) and swap them internally.

Anyway some question.
I will move the falling binding to the port DT node and move the
configuration to mac_config. Should I keep the
dedicated function to setup PAD0 swap or I can directly add the check in
the qca8k_setup for only the bit related to enable the swap?
Andrew Lunn Oct. 9, 2021, 7:47 p.m. UTC | #3
> Problem here is that from Documentation falling edge can be set only on
> PAD0. PAD5 and PAD6 have the related bit reserved.

Meaning in future, they could be used for this, if those ports get
support for SGMII.

> But anyway qca8k support only single sgmii and it's not supported a
> config with multiple sgmii.

Yet, until such hardware appears. We do see more support for SFPs. And
more support for multi-gigi ports. Both of which use a SERDES
interface which can support SGMII. So i would not be too surprised if
future versions of the switch have more ports like this.

> Do we have standard binding for this?

No, there is no standard binding for this. This seems specific to
these devices, maybe a proprietary extension to SGMII?

> About the mac swap. Do we really need to implement a complex thing for
> something that is really implemented internally to the switch?

If it was truly internal to the switch, no. But i don't think it
is. The DSA core has no idea the ports are swapped, and so i think
will put the names on the wrong ports. Does devlink understand the
ports are swapped? How about .ndo_get_phys_port_name? Will udev mix up
the ports?

The way you wanted to look in the other ports DT properties suggests
it is not internal to the switch.

I think to help my understanding, we need some examples of DTS files
with and without the swap, where the properties are read from, what
the interface names are, etc.

> I will move the falling binding to the port DT node and move the
> configuration to mac_config. Should I keep the
> dedicated function to setup PAD0 swap or I can directly add the check in
> the qca8k_setup for only the bit related to enable the swap?

That does not matter too much. DT is an ABI, we should not change it
later, so we need to look forward. C code is not ABI, it can be
changed if/when more SGMII ports actually arrive.

	Andrew
Christian Marangi Oct. 9, 2021, 8:06 p.m. UTC | #4
On Sat, Oct 09, 2021 at 09:47:57PM +0200, Andrew Lunn wrote:
> > Problem here is that from Documentation falling edge can be set only on
> > PAD0. PAD5 and PAD6 have the related bit reserved.
> 
> Meaning in future, they could be used for this, if those ports get
> support for SGMII.
>

Ok. Then I will move all to DT port. Consider falling is set to PAD0 for
both cpu port0 and cpu port6, should I make it hardcoded or should I add
a condition and force the reg to PAD0 only for the current supported
switch? Hope you understand what I mean.
(Yes we have some config with cpu port6 set to sgmii and that require
falling edge)

> > But anyway qca8k support only single sgmii and it's not supported a
> > config with multiple sgmii.
> 
> Yet, until such hardware appears. We do see more support for SFPs. And
> more support for multi-gigi ports. Both of which use a SERDES
> interface which can support SGMII. So i would not be too surprised if
> future versions of the switch have more ports like this.
> 
> > Do we have standard binding for this?
> 
> No, there is no standard binding for this. This seems specific to
> these devices, maybe a proprietary extension to SGMII?
> 

Then we are stuck to the special qca,... naming.

> > About the mac swap. Do we really need to implement a complex thing for
> > something that is really implemented internally to the switch?
> 
> If it was truly internal to the switch, no. But i don't think it
> is. The DSA core has no idea the ports are swapped, and so i think
> will put the names on the wrong ports. Does devlink understand the
> ports are swapped? How about .ndo_get_phys_port_name? Will udev mix up
> the ports?
> 
> The way you wanted to look in the other ports DT properties suggests
> it is not internal to the switch.
> 
> I think to help my understanding, we need some examples of DTS files
> with and without the swap, where the properties are read from, what
> the interface names are, etc.
> 

Here is 2 configuration one from an Netgear r7800 qca8337:

	switch@10 {
		compatible = "qca,qca8337";
		#address-cells = <1>;
		#size-cells = <0>;
		reg = <0x10>;

		qca8k,rgmii0_1_8v;
		qca8k,rgmii56_1_8v;

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				label = "cpu";
				ethernet = <&gmac1>;
				phy-mode = "rgmii-id";

				fixed-link {
					speed = <1000>;
					full-duplex;
				};
			};

			port@1 {
				reg = <1>;
				label = "lan1";
				phy-mode = "internal";
				phy-handle = <&phy_port1>;
			};

			port@2 {
				reg = <2>;
				label = "lan2";
				phy-mode = "internal";
				phy-handle = <&phy_port2>;
			};

			port@3 {
				reg = <3>;
				label = "lan3";
				phy-mode = "internal";
				phy-handle = <&phy_port3>;
			};

			port@4 {
				reg = <4>;
				label = "lan4";
				phy-mode = "internal";
				phy-handle = <&phy_port4>;
			};

			port@5 {
				reg = <5>;
				label = "wan";
				phy-mode = "internal";
				phy-handle = <&phy_port5>;
			};

			port@6 {
				reg = <6>;
				label = "cpu";
				ethernet = <&gmac2>;
				phy-mode = "sgmii";

				fixed-link {
					speed = <1000>;
					full-duplex;
				};
			};
		};

And here is one with mac swap Tp-Link Archer c7 v4 qca8327 

	switch0@10 {
		compatible = "qca,qca8337";
		#address-cells = <1>;
		#size-cells = <0>;

		reg = <0>;
		qca,sgmii-rxclk-falling-edge;
		qca,mac6-exchange;

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				label = "cpu";
				ethernet = <&eth0>;
				phy-mode = "sgmii";

				fixed-link {
					speed = <1000>;
					full-duplex;
				};
			};

			port@1 {
				reg = <1>;
				label = "wan";
				phy-mode = "internal";
				phy-handle = <&phy_port1>;
			};

			port@2 {
				reg = <2>;
				label = "lan1";
				phy-mode = "internal";
				phy-handle = <&phy_port2>;
			};

			port@3 {
				reg = <3>;
				label = "lan2";
				phy-mode = "internal";
				phy-handle = <&phy_port3>;
			};

			port@4 {
				reg = <4>;
				label = "lan3";
				phy-mode = "internal";
				phy-handle = <&phy_port4>;
			};

			port@5 {
				reg = <5>;
				label = "lan4";
				phy-mode = "internal";
				phy-handle = <&phy_port5>;
			};
		};

As you can see we use the mac06_exchange but we declare it as port0. DSA
see it as port0 (as it should as it's internall swapped). We also don't
need to apply some special function or stuff to apply the correct port
in the ACL/regs/VLAN. The switch will treat MAC6 as MAC0 and MAC6 as
MAC0. That is what we observed.
Someone would say... Considering this switch is 2 port... and currently
we use only one port. Why not drop this and use whatever is connected to
port 0. Problem is that some device have the secondary cpu port NOT
connected and they use mac6-exchange and that would result in no
connection since cpu port 0 is not connected and cpu port 6 is never
swapped.

> > I will move the falling binding to the port DT node and move the
> > configuration to mac_config. Should I keep the
> > dedicated function to setup PAD0 swap or I can directly add the check in
> > the qca8k_setup for only the bit related to enable the swap?
> 
> That does not matter too much. DT is an ABI, we should not change it
> later, so we need to look forward. C code is not ABI, it can be
> changed if/when more SGMII ports actually arrive.
> 
> 	Andrew
Andrew Lunn Oct. 9, 2021, 9:37 p.m. UTC | #5
> Here is 2 configuration one from an Netgear r7800 qca8337:
> 
> 	switch@10 {
> 		compatible = "qca,qca8337";
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		reg = <0x10>;
> 
> 		qca8k,rgmii0_1_8v;
> 		qca8k,rgmii56_1_8v;
> 
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			port@0 {
> 				reg = <0>;
> 				label = "cpu";
> 				ethernet = <&gmac1>;
> 				phy-mode = "rgmii-id";
> 
> 				fixed-link {
> 					speed = <1000>;
> 					full-duplex;
> 				};
> 			};
> 
> 			port@1 {
> 				reg = <1>;
> 				label = "lan1";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port1>;
> 			};
> 
> 			port@2 {
> 				reg = <2>;
> 				label = "lan2";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port2>;
> 			};
> 
> 			port@3 {
> 				reg = <3>;
> 				label = "lan3";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port3>;
> 			};
> 
> 			port@4 {
> 				reg = <4>;
> 				label = "lan4";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port4>;
> 			};
> 
> 			port@5 {
> 				reg = <5>;
> 				label = "wan";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port5>;
> 			};
> 
> 			port@6 {
> 				reg = <6>;
> 				label = "cpu";
> 				ethernet = <&gmac2>;
> 				phy-mode = "sgmii";
> 
> 				fixed-link {
> 					speed = <1000>;
> 					full-duplex;
> 				};

So here, it is a second CPU port.  But some other board could connect
an SGMII PHY, and call the port lan5. Or it could be connected to an
SFP cage, and used that way. Or are you forced to use it as a CPU
port, or not use it at all?

> And here is one with mac swap Tp-Link Archer c7 v4 qca8327 
> 
> 	switch0@10 {
> 		compatible = "qca,qca8337";
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		reg = <0>;
> 		qca,sgmii-rxclk-falling-edge;
> 		qca,mac6-exchange;
> 
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			port@0 {
> 				reg = <0>;
> 				label = "cpu";
> 				ethernet = <&eth0>;
> 				phy-mode = "sgmii";
> 
> 				fixed-link {
> 					speed = <1000>;
> 					full-duplex;
> 				};

So when looking for SGMI properties, you need to look here. Where as
in the previous example, you would look in port 6. And the reverse is
true for RGMII delays.

> 			};
> 
> 			port@1 {
> 				reg = <1>;
> 				label = "wan";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port1>;
> 			};
> 
> 			port@2 {
> 				reg = <2>;
> 				label = "lan1";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port2>;
> 			};
> 
> 			port@3 {
> 				reg = <3>;
> 				label = "lan2";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port3>;
> 			};
> 
> 			port@4 {
> 				reg = <4>;
> 				label = "lan3";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port4>;
> 			};
> 
> 			port@5 {
> 				reg = <5>;
> 				label = "lan4";
> 				phy-mode = "internal";
> 				phy-handle = <&phy_port5>;
> 			};
> 		};

So here, port '6' is not used. But it could be connected to an RGMII
PHY and called lan5. Would the naming work out? What does devlink
think of it, etc. What about phy-handle? Is there an external MDIO
bus? What address would be used if there is no phy-handle?

      Andrew
Christian Marangi Oct. 9, 2021, 10:23 p.m. UTC | #6
On Sat, Oct 09, 2021 at 11:37:10PM +0200, Andrew Lunn wrote:
> > Here is 2 configuration one from an Netgear r7800 qca8337:
> > 
> > 	switch@10 {
> > 		compatible = "qca,qca8337";
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> > 		reg = <0x10>;
> > 
> > 		qca8k,rgmii0_1_8v;
> > 		qca8k,rgmii56_1_8v;
> > 
> > 		ports {
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			port@0 {
> > 				reg = <0>;
> > 				label = "cpu";
> > 				ethernet = <&gmac1>;
> > 				phy-mode = "rgmii-id";
> > 
> > 				fixed-link {
> > 					speed = <1000>;
> > 					full-duplex;
> > 				};
> > 			};
> > 
> > 			port@1 {
> > 				reg = <1>;
> > 				label = "lan1";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port1>;
> > 			};
> > 
> > 			port@2 {
> > 				reg = <2>;
> > 				label = "lan2";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port2>;
> > 			};
> > 
> > 			port@3 {
> > 				reg = <3>;
> > 				label = "lan3";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port3>;
> > 			};
> > 
> > 			port@4 {
> > 				reg = <4>;
> > 				label = "lan4";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port4>;
> > 			};
> > 
> > 			port@5 {
> > 				reg = <5>;
> > 				label = "wan";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port5>;
> > 			};
> > 
> > 			port@6 {
> > 				reg = <6>;
> > 				label = "cpu";
> > 				ethernet = <&gmac2>;
> > 				phy-mode = "sgmii";
> > 
> > 				fixed-link {
> > 					speed = <1000>;
> > 					full-duplex;
> > 				};
> 
> So here, it is a second CPU port.  But some other board could connect
> an SGMII PHY, and call the port lan5. Or it could be connected to an
> SFP cage, and used that way. Or are you forced to use it as a CPU
> port, or not use it at all?
>

We have a bit to set the mode. So yes it can be used to different modes.
(base-x, phy and mac)

> > And here is one with mac swap Tp-Link Archer c7 v4 qca8327 
> > 
> > 	switch0@10 {
> > 		compatible = "qca,qca8337";
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> > 
> > 		reg = <0>;
> > 		qca,sgmii-rxclk-falling-edge;
> > 		qca,mac6-exchange;
> > 
> > 		ports {
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			port@0 {
> > 				reg = <0>;
> > 				label = "cpu";
> > 				ethernet = <&eth0>;
> > 				phy-mode = "sgmii";
> > 
> > 				fixed-link {
> > 					speed = <1000>;
> > 					full-duplex;
> > 				};
> 
> So when looking for SGMI properties, you need to look here. Where as
> in the previous example, you would look in port 6. And the reverse is
> true for RGMII delays.
> 
> > 			};
> > 
> > 			port@1 {
> > 				reg = <1>;
> > 				label = "wan";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port1>;
> > 			};
> > 
> > 			port@2 {
> > 				reg = <2>;
> > 				label = "lan1";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port2>;
> > 			};
> > 
> > 			port@3 {
> > 				reg = <3>;
> > 				label = "lan2";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port3>;
> > 			};
> > 
> > 			port@4 {
> > 				reg = <4>;
> > 				label = "lan3";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port4>;
> > 			};
> > 
> > 			port@5 {
> > 				reg = <5>;
> > 				label = "lan4";
> > 				phy-mode = "internal";
> > 				phy-handle = <&phy_port5>;
> > 			};
> > 		};
> 
> So here, port '6' is not used. But it could be connected to an RGMII
> PHY and called lan5. Would the naming work out? What does devlink
> think of it, etc. What about phy-handle? Is there an external MDIO
> bus? What address would be used if there is no phy-handle?
> 
>       Andrew

In this case port6 is not used as it's not connected at all in hardware.
From the configuration list yes, it can be used as lan5 in phy mode and
it would have address 5 (internally the address are with an offset of
-1). Anyway I honestly think that we are putting too much effort in
something that can and should be handled differently. I agree that all
this mac exchange is bs and doesn't make much sense. I tried to
implement this as we currently qca8k is hardcoded to expect
the cpu port 0 for everything and doesn't actually found a valid cpu
port (aka it doesn't expect a configuration with cpu6)
I think the driver was writtent with the concept of mac exchange from
the start. That's why it's hardoced to port0.
I actually tied for fun running the switch using only the port6 cpu
port and it worked just right. So I think I will just drop the mac
exchange and fix the code to make it dynamic.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
index 9383d6bf2426..208ee5bc1bbb 100644
--- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
+++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
@@ -13,6 +13,11 @@  Required properties:
 Optional properties:
 
 - reset-gpios: GPIO to be used to reset the whole device
+- qca,mac6-exchange: Internally swap MAC0 with MAC6.
+- qca,sgmii-rxclk-falling-edge: Set the receive clock phase to falling edge.
+                                Mostly used in qca8327 with CPU port 0 set to
+                                sgmii.
+- qca,sgmii-txclk-falling-edge: Set the transmit clock phase to falling edge.
 - qca,rgmii0-1-8v: Set the internal regulator to supply 1.8v for MAC0 port.
                    This is needed for qca8337 and toggles the supply voltage
                    from 1.5v to 1.8v. For the specific regs it was observed