From nobody Sun Mar 17 17:22:23 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TyPtz64Bmz5DmQS for ; Sun, 17 Mar 2024 17:22:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TyPtz49jGz4Fqf for ; Sun, 17 Mar 2024 17:22:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a46a7b8e07fso144218766b.2 for ; Sun, 17 Mar 2024 10:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1710696154; x=1711300954; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=esQOUBLErd/RtxhZT1J2ljjpoPiC/+niPNHTYP0sEMA=; b=CiwNqZt9qMydzmEexXthV9ltDQ8OktpWpf86xUXWGitXI6fDXJiMwhKPLpt9VdJ9zP cmayxcp5yvfwWd1/7nZGahw20kioj3aAx6Ceps8PkSYoqOp1/VCOY6MQkyDAT0Yalkjh NgsnvXvhN5V0x87NSZtPn4RzI6qtKIMgynYatqkDtaLay/aMf1TtUu8HNuYoATK8HhOm 3OJ2dzagRcvabGA3QSL7EimBPk48DQYQboLMcJS9Gh5NR0JO4coyAUHUUtP+K9JqtM24 q5NGTvtbJhJ5cHpIg1dBpqDzrOApa3Gh5rdB6uKXUAUL1G8Py1CCrrQTmsISsbqBFnp8 Gnqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710696154; x=1711300954; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=esQOUBLErd/RtxhZT1J2ljjpoPiC/+niPNHTYP0sEMA=; b=X537V++Vzwy0Repu7GElQjscHXkWxqlQVlo7GwSv5ZKgGPXbhwA5Tfw7qNbLgZQ13O JI/oA0IFKFg9KwMP/3pMvyiPAS7GvMEthx0/aHj23NH8d4yYc5jG2MWOYDKWXH5E+Psr Z9tz4QIrwSNNkMvto74hzdPG58EAlbGBZVq2dgYYU03bBEehMvOShhhhQeRbISgQ+7SZ J8aZSNQT/552GH0XNGxi0w5aQKYAJ2Oirs1AsFaKr/9P6SxBlE7Inpyf7be7S+FSrOfs A1pz8c3nTTUpGSTDBAJyBPu5m8ebvOOEQFJrE6tB+GOIiMuYcfTOrx65h0AoIRj9ovu1 nckg== X-Forwarded-Encrypted: i=1; AJvYcCVgzuwHwgYZwxYTFXW1Qlve7qlsnBJI1V9Inmho4gg35IsJy2/ZND8FFGUPcignIm5JFpEWU6LSVk/dRzZQjsR6ph0m3RlXqg== X-Gm-Message-State: AOJu0YyqA8wbMch6GPjvsG2ev8WAyOMFL+ZHDBJVvd4RiHFxlQDc7xs1 tDcgY/0zYWgLFemZYvLCtHSKTygM90QbtDBAV/Owi/C/VsKMB74agnDcv7wkGlnJoZXb+bFEDjz vGmRBUBpjyfY1bBaSmNNsWb6I8AifZZ4mFS9Zhg== X-Google-Smtp-Source: AGHT+IFkdUI68j7z/HRdZ7FrPU+vcku/84WeJIHkuloUpwL5lq0PLrhAWaSLwMF+wNXdHZJ8cELeTXraZSEXj8E7DZU= X-Received: by 2002:a17:906:f80c:b0:a3f:1b49:c92b with SMTP id kh12-20020a170906f80c00b00a3f1b49c92bmr5947561ejb.48.1710696153792; Sun, 17 Mar 2024 10:22:33 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <45965774-5534-s0o7-173n-ssq2s1330276@yvfgf.mnoonqbm.arg> <86msqx6phk.fsf@peasant.tower.home> In-Reply-To: <86msqx6phk.fsf@peasant.tower.home> From: Warner Losh Date: Sun, 17 Mar 2024 11:22:23 -0600 Message-ID: Subject: Re: connect a "loose" device to a OFW/FDT node (and then use mii_fdt)? To: Dmitry Salychev Cc: "Bjoern A. Zeeb" , freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000090e3b20613de7cfa" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4TyPtz49jGz4Fqf --00000000000090e3b20613de7cfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2024 at 5:56=E2=80=AFAM Dmitry Salychev w= rote: > > Hi, > > I'd like to suggest a real world example of the case described by bz@. > (please, excuse its verbosity) > > ----- dmesg ----- > dpaa2_mac3: dpmcp (id=3D27) at dpmac (id=3D7) on dpaa2_rc0 > dpaa2_mac3: max_rate=3D1000, eth_if=3DQSGMII, link_type=3DPHY > ... > paa2_mac_fdt6: 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: ... 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: on memacphy_fdt0 > vscphy0: 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 > simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus > ofwbus0 > nexus0 > > dpaa2_mac_fdt6 /* compat=3Dfsl,qoriq-mc-dpmac */ > dpaa2_mc0 pnpinfo name=3Dfsl-mc@80c000000 compat=3Dfsl,qoriq-mc > simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus > 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 > simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus > 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. > So FDT name dpmac7 (FreeBSD device dpaa2_mac3) has a pointer to the PHY mdio1_phy1 (FreeBSD name dpaa2_ni0). Neither looks like a detached device at all. Both are parts of parallel device trees, with points from one tree to the other. The problem, though, becomes one of ordering: you'd need to at least probe all the devices before you could start to attach, or you'd need a callback when your target device attaches. Something needs to know when all the parts are there to allow the mii_attach to be called. This isn't a generic 'what to do with detached devices' problem in so much as a 'what do we do in the embedded world where a FreeBSD logical device is made up of several physical devices in the FDT tree, which effectively attach asynchronously' since the order of attach is implemented as in DTB order, but is actually undefined. If the dependencies aren't there, how do you, in a generic way, register for a callback when they are (or alternatively, how do you create a 'set' of FDT devices (which you can know at any time) that has a way to know when all the devices are present so that the rest of the device's attach can happen (and you can do mii_attach, etc). And how do you make that robust enough to inform the user when device sets are incomplete. It's the opposite problem of refcounting a resource to free it, in many ways. Right now, there's nothing generic. It's all ad-hoc. I'd agree that this is a less than ideal approach since you'd also want to be able to handle situations where the driver isn't there initially, but was loaded after mountroot (though this is likely uncommon, it's not unknown to have drivers that work when loaded from userland, but not the loader due to ordering bugs in the driver itself that aren't yet solved). The traditional 'we have all our dependencies in attach because all we care about is decoding (so just our parents) and everything is on the 'card' that we've written drivers for' isn't such a good fit here, I'll grant. And unfortunately, the current answer is that cooperative devices figure it out themselves, which is an unsatisfying answer. That's the basis for the inquiry, right? If we had a callback that waited for all components to be present (or other components to be present), then we could drive this via a state machine that would have clear ordering and responsibilities (though the exact nature of those would be device dependent). It's quite unlikely that we'll ever support randomly attaching one part of the FDT to another because that causes other problems... IIRC, Ian and I did experiments in that area years ago and nothing but trouble came from it for arbitrary topologies (though we did get some specific ones working). Warner > [1] https://www.kernel.org/doc/html/next/networking/phy-link-topology.htm= l > [2] https://www.kernel.org/doc/html/latest/networking/sfp-phylink.html > > Regards, > Dmitry > > Warner Losh 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/FD= T. > > > > 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 tha= t > 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' an= d > 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 > --00000000000090e3b20613de7cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 17, 2024 at 5:56=E2=80=AF= AM Dmitry Salychev <dsl@freebsd.org> wrote:
Hi,

I'd like to suggest a real world example of the case described by bz@.<= br> (please, excuse its verbosity)

----- dmesg -----
dpaa2_mac3: <DPAA2 MAC> dpmcp (id=3D27) at dpmac (id=3D7) on dpaa2_rc= 0
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)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 */
=C2=A0dpaa2_rc0 /* DPAA2 resource container, firmware bus */
=C2=A0dpaa2_mc0 pnpinfo name=3Dfsl-mc@80c000000 compat=3Dfsl,qoriq-mc
=C2=A0simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus
=C2=A0ofwbus0
=C2=A0nexus0

dpaa2_mac_fdt6 /* compat=3Dfsl,qoriq-mc-dpmac */
=C2=A0dpaa2_mc0 pnpinfo name=3Dfsl-mc@80c000000 compat=3Dfsl,qoriq-mc
=C2=A0simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus
=C2=A0ofwbus0
=C2=A0nexus0

vscphy0 pnpinfo oui=3D0x8083 model=3D0x27 rev=3D0x0 at phyno=3D28
=C2=A0miibus0
=C2=A0memacphy_fdt0 /* implements MII interface */
=C2=A0memac_mdio_fdt0 pnpinfo name=3Dmdio@8b96000 compat=3Dfsl,fman-memac-m= dio
=C2=A0simplebus0 pnpinfo name=3Dsoc compat=3Dsimple-bus
=C2=A0ofwbus0
=C2=A0nexus0
----- devinfo -----
----- FDT -----
fsl_mc: fsl-mc@80c000000 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D "fsl,qoriq-mc";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dpmacs {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dpmac7: ethernet@7 = {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 compatible =3D "fsl,qoriq-mc-dpmac";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 reg =3D <7>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 phy-handle =3D <&mdio1_phy1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 phy-connection-type =3D "qsgmii";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 pcs-handle =3D <&pcs7_0>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 managed =3D "in-band-status";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
};
emdio1: mdio@8b96000 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 compatible =3D "fsl,fman-memac-mdio";=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reg =3D <0x0 0x8b96000 0x0 0x1000>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 little-endian;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 #address-cells =3D <1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 #size-cells =3D <0>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 clock-frequency =3D <2500000>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 clocks =3D <&clockgen QORIQ_CLK_PLATFORM= _PLL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 QORIQ_CLK_PLL_DIV(1)>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mdio1_phy1: ethernet-phy@1c {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reg =3D <0x1c>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 };
};
----- 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.

This isn't a generic 'what to= do with detached devices' problem in so much as a 'what do we do i= n the embedded world where a FreeBSD logical device is made up of several p= hysical devices in the FDT tree, which effectively attach asynchronously= 9; since the order of attach is implemented as in DTB order, but is actuall= y undefined.=C2=A0 If the dependencies aren't there, how do you, in a g= eneric way, register for a callback when they are (or alternatively, how do= you create a 'set' of FDT devices (which you can know at any time)= that has a way to know when all the devices are present so that the rest o= f the device's attach can happen (and you can do mii_attach, etc). And = how do you make that robust enough to inform the user when device sets are = incomplete. It's the opposite problem of refcounting a resource to free= it, in many ways.


The traditi= onal 'we have all our dependencies in attach because all we care about = is decoding (so just our parents) and everything is on the 'card' t= hat we've written drivers for' isn't such a good fit here, I= 9;ll grant. And unfortunately, the current answer is that cooperative devic= es figure it out themselves, which is an unsatisfying answer.=C2=A0 That= 9;s the basis for the inquiry, right? If we had a callback that waited for = all components to be present (or other components to be present), then we c= ould drive this via a state machine that would have clear ordering and resp= onsibilities (though the exact nature of those would be device dependent). = It's quite unlikely that we'll ever support randomly attaching one = part of the FDT to another because that causes other problems... IIRC, Ian = and I did experiments in that area years ago and nothing but trouble came f= rom it for arbitrary topologies (though we did get some specific ones worki= ng).

[1] https://www.kernel.org/doc/html/next/networking/phy-link-topology.h= tml
[2] https://www.kernel.org/doc/htm= l/latest/networking/sfp-phylink.html

Regards,
Dmitry

Warner Losh <imp@bsd= imp.com> writes:

> On Tue, Feb 27, 2024 at 1:40=E2=80=AFPM Bjoern A. Zeeb <bzeeb-lists@lists.= zabbadoz.net> wrote:
>
>=C2=A0 Hi,
>
>=C2=A0 I have a device which has its own ivars and is not created from = OFW/FDT.
>
> How does it get this knowledge then?
>=C2=A0
>=C2=A0 The parent(parent(dev)) was but FDT does not fully represent the= logic
>=C2=A0 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 th= at 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, bu= t I could be mistaken.
>=C2=A0
>=C2=A0 I tried to put ASCII art below (try a plain text view if needed)= .
>
>=C2=A0 Is there any way to connect this "mac" device to its r= elevant node in FDT
>=C2=A0 (continuing the "tree" there) and then use mii_fdt to = attach (doing
>=C2=A0 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.
>
>=C2=A0 So looks something like this:
>
>=C2=A0 =C2=A0 X (ofw/fdt/simplebus node/device)
>=C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 +--- 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 jus= t another bus. It will have whatever children are proper for
> that bus to have. It's up to it to make that determination.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----- 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 su= per class.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---- mi= ibus(_fdt if possible)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+------ PHY
>
> Usually the non-linear references to PHYs that live on a MIIBUS not di= rectly 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 direc= t 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 whic= h 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 w= rappers that forwarded all the relevant newbus methods
> called on behalf of driver A to driver B and vice versa. Though I do r= ecall it was a pain in some spots since simple operations
> couldn't be directly coded.
>
> Warner

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