Re: Ethernet device with shared mdio

On Fri, 6 Sep 2024 18:03:39 +0000
Mike Belanger <[email protected]> wrote:

> The following device tree specifies a shared mdio.
> The ffec driver uses miibus.
> When there is a shared mdio, one of the device instances will not be
> able to properly configure the PHY, as it needs to use the other
> devices resource to read/write the PHY.
> 
> &fec1 {pinctrl-names = "default";
>        pinctrl-0 = <&pinctrl_fec1>;
>        phy-mode = "rgmii-id";
>        phy-handle = <&ethphy0>;
>        fsl,magic-packet;
>        status = "okay";
> 
>        mdio {
>              #address-cells = <1>;
>              #size-cells = <0>;
> 
>              ethphy0: ethernet-phy@0 {
>                                       compatible = "ethernet-phy-ieee802.3-c22"; reg = <0>;
>              };
> 
>              ethphy1: ethernet-phy@1 {
>                                       compatible = "ethernet-phy-ieee802.3-c22"; reg = <1>;
>              };
>        };
> };
> 
> &fec2 {
>        pinctrl-names = "default";
>        pinctrl-0 = <&pinctrl_fec2>;
>        phy-mode = "rgmii-txid";
>        phy-handle = <&ethphy1>;
>        phy-supply = <&reg_fec2_supply>;
>        nvmem-cells = <&fec_mac1>;
>        nvmem-cell-names = "mac-address";
>        rx-internal-delay-ps = <2000>;
>        fsl,magic-packet;
>        status = "okay";
> };
> 
> Does FreeBSD have any plans for supporting hardware that specifies a
> shared mdio in the dtb? Just knowing the general approach being
> considered would be helpful.
> 

I can't speak for FreeBSD project, I just can share my experience with
similar case. It is described in my post to hackers mailing list (see
https://lists.freebsd.org/archives/freebsd-hackers/2021-December/000649.html
for details), unfortunately, no response received. Another attempt to
get some attention a week later on net mailing list was done, see
https://lists.freebsd.org/archives/freebsd-net/2021-December/001114.html
for the post, with no response either.

As you see, my case was similar, just the mdio block was attached to
second controller. This makes it a bit more problematic - you can't use
mdio controller before being initialized, naturally.

I was not able to use miiproxy approach as noted in my post to hackers
mailing list, additionally, miiproxy was removed from the tree with
MIPS arch some time later. I resolved the issue by modifying cgem driver
and mii layer. This was just a proof of concept with some hacks, but I
was able to use both ports with proper link state change detection. I
did not continue the work because vendor changed hardware design and
there was no shared mdio anymore.

If you are interested I can dig for the sources, big part of my changes
would not be necessary, just the idea of decoupling MDIO and MII
interfaces still applies, I think. By the way, which board are you
working on? Is it accessible for general audience?

Regards,
Milan