Thank you for the response and for sharing your scenario.
We’ve also hacked up the cgem and the ffec driver to support a shared mdio.
That was not too difficult, but we have a new scenario where the mdio is now
being shared between two different devices that use different drivers (ffec and
eqos).
This presents a few extra challenges.
I was hoping that FreeBSD may have considered supporting a shared mdio. We can
come up with something, but if there is an existing architecture/approach in
the works…we would like to use a consistent approach. At first glance,
miiproxy did not seem like a fit.
I do not have the hardware. I am trying to help somebody else with this. I
have seen the dtb.
It’s a Variscite DAR-MX8M-PLUS.
Regards,
Mike.
From: owner-freebsd-...@freebsd.org <owner-freebsd-...@freebsd.org> on behalf
of Milan Obuch <freebsd-...@dino.sk>
Date: Friday, September 13, 2024 at 3:08 AM
To: freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Re: Ethernet device with shared mdio
CAUTION - This email is from an external source. Please be cautious with links
and attachments. (go/taginfo)
On Fri, 6 Sep 2024 18:03:39 +0000
Mike Belanger <mibelan...@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://urldefense.com/v3/__https://lists.freebsd.org/archives/freebsd-hackers/2021-December/000649.html__;!!JoeW-IhCUkS0Jg!fv0DHFN5Xb4FbKwre1H4UDCUvbmhAoO1y5HgQiDkN6wuv2t3B4pyS1akuKuCn6ZqO1AfbrCaFsVsJibdfui4KfJQGw$<https://urldefense.com/v3/__https:/lists.freebsd.org/archives/freebsd-hackers/2021-December/000649.html__;!!JoeW-IhCUkS0Jg!fv0DHFN5Xb4FbKwre1H4UDCUvbmhAoO1y5HgQiDkN6wuv2t3B4pyS1akuKuCn6ZqO1AfbrCaFsVsJibdfui4KfJQGw$>
for details), unfortunately, no response received. Another attempt to
get some attention a week later on net mailing list was done, see
https://urldefense.com/v3/__https://lists.freebsd.org/archives/freebsd-net/2021-December/001114.html__;!!JoeW-IhCUkS0Jg!fv0DHFN5Xb4FbKwre1H4UDCUvbmhAoO1y5HgQiDkN6wuv2t3B4pyS1akuKuCn6ZqO1AfbrCaFsVsJibdfujKN3_xCA$<https://urldefense.com/v3/__https:/lists.freebsd.org/archives/freebsd-net/2021-December/001114.html__;!!JoeW-IhCUkS0Jg!fv0DHFN5Xb4FbKwre1H4UDCUvbmhAoO1y5HgQiDkN6wuv2t3B4pyS1akuKuCn6ZqO1AfbrCaFsVsJibdfujKN3_xCA$>
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
----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
