cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
einglis
Visitor
Visitor
610 Views
Registered: ‎01-08-2020

Shared MDIO bus - Again...

Jump to solution

A long-time lurker writes:

I'm aware that there are many, many posts on the issue of using two or more Ethernet PHYs with a single PS MAC on a shared MDIO bus.  Somehow, though, they don't form a consistent picture.  I'm hoping to join some more dots with this question...

Firstly, the "accepted" AR69132 offers patches[1] that are apparently required for 2017.x and 2018.x Linux, and describes a corresponding Device Tree[2], but the MACB driver page implies that it 'just works' unmodified.  With that said, that page _does_ reference the magic AR, but only if you're lucky enough to notice it.  The DT example on this page is quite different.  And then I've seen posts here and there that suggest no patches are needed for 2019.x.

[1] - The official patches hide the real meat of the change away, by making two changes at once: splitting functionality into a separate file, and making whatever the 'important' change is.  To make matters worse, the Xilinx repo version differ from the vanilla Linux repo that I'd rather use.

[2] - The device tree example is confusing.  The MACB page suggests this sort of thing:

&gem0 {
  phy-handle = &phy-a
  phy-a { ... }
  phy-b { ... }
}
&gem1 { 
  phy-handle = &phy-b
}

Other sources say something like:

mdio {
  phy-a { ... }
  phy-b { ... }
}
&gem0 {
  ... &phy-a
}
&gem1 {
  ... &phy-b
}

The AR suggests something very similar, but decorates the `mdio` section considerably:

mdio {
  compatible = "cdns,macb-mdio";
  regs ...
  clocks ...
}

Suddenly, the MDIO _bus_ has its own _driver_, which is a little strange in itself.

Also: the regs in the example "<0x 0xff0b0000, 0x0, 0x1000>" look very much like the regs for eth0.  Are they the same, or is it a coincidence?  And what happens to the regs for the primary eth0 and eth1 definitions?

There's a similar story for the clocks, with the AR showing "clk125" three times, while other examples I've seen re-use the eth0 clocks.  So confusing!

As a final confounding factor, for years, everyone seemed to use "0xe000b000" and "0xe000c000" for eth0 and eth1, and suddenly all the examples use "0xff0b0000".  Is this just a change of convention?  I _really_, _really_ don't want to re-generate my PL and handoff files.

 

Afterword:

The community seems to be struggling as a whole with what is obviously a very common concern.  At the same time, the other half of the community is being very helpful, but the answers don't seem to mesh into a complete picture.

I do hope this turns out to be a constructive message and not just a rant!  Please let me know if I can provide any more details that might guide answers.

1 Solution

Accepted Solutions
einglis
Visitor
Visitor
513 Views
Registered: ‎01-08-2020

Coming back to answer my own question, at least partly.

I managed to get the 2018.3 patches applied pretty straightforwardly.  I'm actually using vanilla 4.14, so the patch needed a bit of tweaking, but nothing major.  I had complained that by moving code into a new file hid the meat of the change.  It seems that the main point was to change the Device Tree parsing to be more explicit about locating the PHYs; rather than doing it as part of the MAC bringup, it's now its own step.  I was expecting a bug fix nestled in there as well.  (In my own team, I'd have asked for a two-step patch: the first that adds the new functionality in a new file, and a second that then moves the old code around for neatness, but there we are.)

Anyway, the upshot is that I ended up with a Device Tree of this form:

/ {
  ...
	mdio {
		compatible = "cdns,macb-mdio";
		clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
		clock-names = "pclk", "hclk", "tx_clk";
		reg = <0xe000b000 0x1000>;

		#address-cells = <1>;
		#size-cells = <0>;
		phy0: phy@0 {
			device_type = "ethernet-phy";
			reg = <0>;
		} ;
		phy1: phy@1 {
			device_type = "ethernet-phy";
			reg = <1>;
		};
	};
};

...

&gem0 {
	local-mac-address = [00 0a 35 00 00 00];
	phy-mode = "rgmii-id";
	status = "okay";
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	phy-handle = <&phy0>;
};

&gem1 {
	local-mac-address = [00 0a 35 00 00 02];
	phy-mode = "rgmii-id";
	status = "okay";
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	phy-handle = <&phy1>;
};

With this, the MDIO section just duplicates the clocks and registers from GEM0, and the GEM0 and GEM1 sections themselves remain unchanged.  My concern about the registers shifting from one form to another appears to be a red herring.

 

Finally, I looked into the claim that 2019.x needs no such patch.  This seems to be born out by this patch: "net: macb: add support for mdio phy nodes" , which basically seems to be trying to do the same thing in a much lighter-weight way.  Having said that, I was unable to make it work for me.  I tried many permutations of the Device Tree, but always ended up with the kernel complaining about NULL Parent KObjects, or such like.  An issue for future code explorers to answer, I guess.

 

View solution in original post

1 Reply
einglis
Visitor
Visitor
514 Views
Registered: ‎01-08-2020

Coming back to answer my own question, at least partly.

I managed to get the 2018.3 patches applied pretty straightforwardly.  I'm actually using vanilla 4.14, so the patch needed a bit of tweaking, but nothing major.  I had complained that by moving code into a new file hid the meat of the change.  It seems that the main point was to change the Device Tree parsing to be more explicit about locating the PHYs; rather than doing it as part of the MAC bringup, it's now its own step.  I was expecting a bug fix nestled in there as well.  (In my own team, I'd have asked for a two-step patch: the first that adds the new functionality in a new file, and a second that then moves the old code around for neatness, but there we are.)

Anyway, the upshot is that I ended up with a Device Tree of this form:

/ {
  ...
	mdio {
		compatible = "cdns,macb-mdio";
		clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
		clock-names = "pclk", "hclk", "tx_clk";
		reg = <0xe000b000 0x1000>;

		#address-cells = <1>;
		#size-cells = <0>;
		phy0: phy@0 {
			device_type = "ethernet-phy";
			reg = <0>;
		} ;
		phy1: phy@1 {
			device_type = "ethernet-phy";
			reg = <1>;
		};
	};
};

...

&gem0 {
	local-mac-address = [00 0a 35 00 00 00];
	phy-mode = "rgmii-id";
	status = "okay";
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	phy-handle = <&phy0>;
};

&gem1 {
	local-mac-address = [00 0a 35 00 00 02];
	phy-mode = "rgmii-id";
	status = "okay";
	xlnx,ptp-enet-clock = <0x69f6bcb>;
	phy-handle = <&phy1>;
};

With this, the MDIO section just duplicates the clocks and registers from GEM0, and the GEM0 and GEM1 sections themselves remain unchanged.  My concern about the registers shifting from one form to another appears to be a red herring.

 

Finally, I looked into the claim that 2019.x needs no such patch.  This seems to be born out by this patch: "net: macb: add support for mdio phy nodes" , which basically seems to be trying to do the same thing in a much lighter-weight way.  Having said that, I was unable to make it work for me.  I tried many permutations of the Device Tree, but always ended up with the kernel complaining about NULL Parent KObjects, or such like.  An issue for future code explorers to answer, I guess.

 

View solution in original post