Re: connect a "loose" device to a OFW/FDT node (and then use mii_fdt)?

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=27) at dpmac (id=7) on dpaa2_rc0
dpaa2_mac3: max_rate=1000, eth_if=QSGMII, link_type=PHY
..
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=7)
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=fsl-mc@80c000000 compat=fsl,qoriq-mc 
 simplebus0 pnpinfo name=soc compat=simple-bus 
 ofwbus0
 nexus0

dpaa2_mac_fdt6 /* compat=fsl,qoriq-mc-dpmac */
 dpaa2_mc0 pnpinfo name=fsl-mc@80c000000 compat=fsl,qoriq-mc 
 simplebus0 pnpinfo name=soc compat=simple-bus 
 ofwbus0
 nexus0

vscphy0 pnpinfo oui=0x8083 model=0x27 rev=0x0 at phyno=28
 miibus0
 memacphy_fdt0 /* implements MII interface */
 memac_mdio_fdt0 pnpinfo name=mdio@8b96000 compat=fsl,fman-memac-mdio 
 simplebus0 pnpinfo name=soc compat=simple-bus 
 ofwbus0
 nexus0
----- devinfo -----
----- FDT -----
fsl_mc: fsl-mc@80c000000 {
	compatible = "fsl,qoriq-mc";
	...
	dpmacs {
		...
		dpmac7: ethernet@7 {
			compatible = "fsl,qoriq-mc-dpmac";
			reg = <7>;
                        phy-handle = <&mdio1_phy1>;
	                phy-connection-type = "qsgmii";
	                pcs-handle = <&pcs7_0>;
	                managed = "in-band-status";
		};
		...
	};
};
emdio1: mdio@8b96000 {
	compatible = "fsl,fman-memac-mdio";
	reg = <0x0 0x8b96000 0x0 0x1000>;
	little-endian;
	#address-cells = <1>;
	#size-cells = <0>;
	clock-frequency = <2500000>;
	clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL
			    QORIQ_CLK_PLL_DIV(1)>;
	...
	mdio1_phy1: ethernet-phy@1c {
		reg = <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 <[email protected]> writes:

> On Tue, Feb 27, 2024 at 1:40 PM Bjoern A. Zeeb <[email protected]> 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?
>  
>  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 would 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 relationship 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 be mistaken.
>  
>  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 that 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 another bus. It will have whatever children are proper for
> that bus to have. It's up to it to make that determination.
>  
>         |
>         +----- 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 node in the tree?
>
> But regardless, you could create any device you want as a child of X, though 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.
>  
>                  |
>                  +---- miibus(_fdt if possible)
>                           |
>                           +------ PHY
>
> Usually the non-linear references to PHYs that live on a MIIBUS not directly 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 control 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 case 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 this years ago with some stuff that never made it into the
> tree on a consulting basis and it was relatively simple to write the wrappers that forwarded all the relevant newbus methods
> called on behalf of driver A to driver B and vice versa. Though I do recall it was a pain in some spots since simple operations
> couldn't be directly coded.
>
> Warner

-- 
https://wiki.freebsd.org/DmitrySalychev