Date: Sun, 17 Mar 2024 11:27:39 +0100 From: Dmitry Salychev <dsl@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-arm@freebsd.org Subject: Re: connect a "loose" device to a OFW/FDT node (and then use mii_fdt)? Message-ID: <86msqx6phk.fsf@peasant.tower.home> In-Reply-To: <CANCZdfqgvrqy94KnU685_3NKJNLT4OUhn_iB2JhtNtZjWjCE0Q@mail.gmail.com> References: <45965774-5534-s0o7-173n-ssq2s1330276@yvfgf.mnoonqbm.arg> <CANCZdfqgvrqy94KnU685_3NKJNLT4OUhn_iB2JhtNtZjWjCE0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I'd like to suggest a real world example of the case described by bz@.
(please, excuse its verbosity)
----- dmesg -----
dpaa2_mac3: <DPAA2 MAC> dpmcp (id=3D27) at dpmac (id=3D7) on dpaa2_rc0
dpaa2_mac3: max_rate=3D1000, eth_if=3DQSGMII, link_type=3DPHY
...
paa2_mac_fdt6: <DPAA2 MAC DEV> on dpaa2_mc0
dpaa2_mac_fdt6: node 0x49f4 'ethernet@7': reg 0x7 sfp 0 \
pcs-handle 0x3f7c phy-handle 0x3984 managed 'in-band-status' \
phy-conn-type 'qsgmii'
...
dpaa2_ni0: <DPAA2 Network Interface> ... on dpaa2_rc0
dpaa2_ni0: connected to dpmac (id=3D7)
dpaa2_ni0: connected DPMAC is in PHY mode
dpaa2_mc0: dpmac_id 7 mdev 0xffffa0800203c800 (dpaa2_mac_fdt6)
pdev 0xffffa08000fc8300 (memacphy_fdt0)
miibus0: <MII bus> on memacphy_fdt0
vscphy0: <Vitesse VSC8514 10/100/1000TX PHY> PHY 28 on miibus0
...
----- dmesg -----
----- devinfo -----
dpaa2_mac3 /* DPAA2 MAC abstraction */
dpaa2_rc0 /* DPAA2 resource container, firmware bus */
dpaa2_mc0 pnpinfo name=3Dfsl-mc@80c000000 compat=3Dfsl,qoriq-mc=20
simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus=20
ofwbus0
nexus0
dpaa2_mac_fdt6 /* compat=3Dfsl,qoriq-mc-dpmac */
dpaa2_mc0 pnpinfo name=3Dfsl-mc@80c000000 compat=3Dfsl,qoriq-mc=20
simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus=20
ofwbus0
nexus0
vscphy0 pnpinfo oui=3D0x8083 model=3D0x27 rev=3D0x0 at phyno=3D28
miibus0
memacphy_fdt0 /* implements MII interface */
memac_mdio_fdt0 pnpinfo name=3Dmdio@8b96000 compat=3Dfsl,fman-memac-mdio=20
simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus=20
ofwbus0
nexus0
----- devinfo -----
----- FDT -----
fsl_mc: fsl-mc@80c000000 {
compatible =3D "fsl,qoriq-mc";
...
dpmacs {
...
dpmac7: ethernet@7 {
compatible =3D "fsl,qoriq-mc-dpmac";
reg =3D <7>;
phy-handle =3D <&mdio1_phy1>;
phy-connection-type =3D "qsgmii";
pcs-handle =3D <&pcs7_0>;
managed =3D "in-band-status";
};
...
};
};
emdio1: mdio@8b96000 {
compatible =3D "fsl,fman-memac-mdio";
reg =3D <0x0 0x8b96000 0x0 0x1000>;
little-endian;
#address-cells =3D <1>;
#size-cells =3D <0>;
clock-frequency =3D <2500000>;
clocks =3D <&clockgen QORIQ_CLK_PLATFORM_PLL
QORIQ_CLK_PLL_DIV(1)>;
...
mdio1_phy1: ethernet-phy@1c {
reg =3D <0x1c>;
};
};
----- FDT -----
dpaa2_rc (resource container) acts like a firmware bus and allows to
discover DPAA2 devices (like dpaa2_mac) via commands implemented in the
MC (management complex) firmware without traversing FDT. However,
the firmware itself doesn't implement commands to retrieve a PHY link
topology[1] yet.
FDT describes the PHY topology in this case and we're only creating
auxiliary drivers (like dpaa2_mac_fdt, memac_mdio_fdt and memacphy_fdt)
in order to gather all of the necessary pieces of information and call
mii_attach() somewhere in the dpaa2_ni (network interface).
Personally, I don't think our current approach is good one because:
(a) it isn't clear who is responsible to extract and form a description
of the PHY topology and (b) auxiliary drivers provide no unified
interface to obtain information extracted from FDT.
dpaa2_mc (or dpaa2_rc) could be responsible for the information
extraction in order to provide dpaa2_mac with everything needed to
create a PHY link topology in its softc[2], I think.
[1] https://www.kernel.org/doc/html/next/networking/phy-link-topology.html
[2] https://www.kernel.org/doc/html/latest/networking/sfp-phylink.html
Regards,
Dmitry
Warner Losh <imp@bsdimp.com> writes:
> On Tue, Feb 27, 2024 at 1:40=E2=80=AFPM Bjoern A. Zeeb <bzeeb-lists@lists=
.zabbadoz.net> wrote:
>
> Hi,
>
> I have a device which has its own ivars and is not created from OFW/FDT.
>
> How does it get this knowledge then?
>=20=20
> The parent(parent(dev)) was but FDT does not fully represent the logic
> of it and we need to create the intermediate device *sigh*
>
> FDT just describes hardware, which is often non-linear where a driver wou=
ld need to speak to two different devices to
> accomplish its needs. A common example of this has been NIC drivers that =
don't have any access to the mii bus to talk to the
> PHY that controls it, so has to do what's normally a parent/child relatio=
nship in add-in cards via a proxy. From what you
> described below, it looks like that's what's going on here, but I could b=
e mistaken.
>=20=20
> I tried to put ASCII art below (try a plain text view if needed).
>
> Is there any way to connect this "mac" device to its relevant node in FDT
> (continuing the "tree" there) and then use mii_fdt to attach (doing
> all the PHY stuff and references)?
>
> You'd likely have to proxy the miibus that the phy is connected to so tha=
t the NIC can talk to its PHY via this intermediary.
>
> So looks something like this:
>
> X (ofw/fdt/simplebus node/device)
> |
> +--- interim dev (not in FDT created by X)
>
> If there's no hardware, why is this device created?
>
> However, assuming that there's a good reason, this X device is just anoth=
er bus. It will have whatever children are proper for
> that bus to have. It's up to it to make that determination.
>=20=20
> |
> +----- mac dev (in FDT but created as child of 'interim dev' and =
not out of ofw/fdt/simplebus)
>
> Wouldn't there be a PHANDLE or similar reference then pointing to this no=
de in the tree?
>
> But regardless, you could create any device you want as a child of X, tho=
ugh in this case it is a little weird if the mac doesn't
> belong to something else that would be a simple bus or a simple bus super=
class.
>=20=20
> |
> +---- miibus(_fdt if possible)
> |
> +------ PHY
>
> Usually the non-linear references to PHYs that live on a MIIBUS not direc=
tly connected to the mac are done through cooperation
> between the PHY driver and the MAC driver. One could model it the way you=
are saying, but that's not a requirement. We've
> had several of these come up over the years since many SoCs have direct c=
ontrol of the MII bus not through resources owned
> by the NIC as is often the case with add-in cards.
>
> So the question would become, is that the real situation here (in which c=
ase you'd need to proxie messages between the NIC
> and PHY) or is it something else?
>
> I can't recall if we have drivers in the tree that do this today. I did t=
his years ago with some stuff that never made it into the
> tree on a consulting basis and it was relatively simple to write the wrap=
pers that forwarded all the relevant newbus methods
> called on behalf of driver A to driver B and vice versa. Though I do reca=
ll it was a pain in some spots since simple operations
> couldn't be directly coded.
>
> Warner
--=20
https://wiki.freebsd.org/DmitrySalychev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86msqx6phk.fsf>