Date: Fri, 13 Sep 2024 09:07:47 +0200 From: Milan Obuch <freebsd-net@dino.sk> To: freebsd-net@freebsd.org Subject: Re: Ethernet device with shared mdio Message-ID: <20240913090747.48062204@zeta.dino.sk> In-Reply-To: <YQXPR01MB4198A8ED40891B0B51B5A4F6BC9E2@YQXPR01MB4198.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR01MB4198A8ED40891B0B51B5A4F6BC9E2@YQXPR01MB4198.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Sep 2024 18:03:39 +0000
Mike Belanger <mibelanger@blackberry.com> 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 = <ðphy0>;
> 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 = <ðphy1>;
> phy-supply = <®_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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240913090747.48062204>