From nobody Sun Mar 17 10:27:39 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 4TyGfy1N83z5CyQv for ; Sun, 17 Mar 2024 11:56:42 +0000 (UTC) (envelope-from dsl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TyGfy0rvPz4V9k; Sun, 17 Mar 2024 11:56:42 +0000 (UTC) (envelope-from dsl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710676602; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WFAdMUsePLbCG18tbnohFoib9fqwb0/4n2oHv3dtgIA=; b=t8dAP708FCODr0ujMPDXCfYuY0GSBvx9WxAPcNy+wQ8EuKcPn1KAO0q0hk2lsS2IedURfq te7ID9b3lKDZgfLE0oxa3aqSSYNbNhAMkGZNzMs3thdxiUHpNY/lk97UnvbJBDZw7xhVIu e9IuDT0tbczOvWIpGoEtKBMZEciGcGuepUPcxxIjDzQU/ULzGwqMpzu+j+mZRE/G+vT1aF /Ro7bpxiWaOrq6vf7P67mIXU5NUv0vbvpzISZgOzw57tpJaQqCnVFryXsvilK3fO3/mYxE XxzMETELgtpF1AumHlEgLtGeibVT9aGqwnZ+5FTY4qFuRsLFF4fnjdL6IjIfog== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1710676602; a=rsa-sha256; cv=none; b=C88Twm8x2BGMShpjoW4Tw3y956yfsalHeKuT+VguHFqOMJ55vpBdDTRwwRc0B5X4q3Wwf1 5wJKxNqlPtnFkZsMH33/ETaTMWcY1wYB4btpzj86Iq6C02SNq0GWdqPAoY1dM12BH/xZh8 kG2etBGqA4YisqF9ZbblfYa54EUXQfPn3BxcCfYuXFnV1i1XeV+BPBhRuYXrFwne/b6jaN VmhIWNEIV1zYA6Zw6g0WvFlxbr7tlgBvVTchLHZalAbuF89YE4PD4b49hjYvo7i3UZeRlq u2rmSsehQuvY2eCgsdEzZuE/AnWKOO/K0/ieX1TgCIeUkSq5gz/7khB29Fw3gQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1710676602; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WFAdMUsePLbCG18tbnohFoib9fqwb0/4n2oHv3dtgIA=; b=dyMpaXpmIjAiz1T74OMFnBzrGGInI8ZWlDO27ZwZIxnCxif0RRJct+3Q6xNCKkiw82Oj3e /8/4e+RDpXJJHXNINcGUBkJ2bbqXSaMqlPqdyIcpV3h0J+BQA55Aefb3IyKXUH58eQvzSB AcefKmqwYhpgwOvW69J0tbVaW3nWqTdrVBJHy0m2eVTJHzCvv55QskgMJTb0Hm2Jgfxn6d KPKmE5r+7hDO7r80pgkBvemtnSNqX86tzhMPw6nbGt6ZbtDAoBv/r6e7K9fpc1R1LVvWpN i6894qYgP8QcT3TM+3NfY6c8wC5c5G6eOPfLHC5i6keCA3gKKgQiO4azRm1rLQ== Received: from localhost (unknown [91.226.51.235]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: dsl) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TyGfx53tcz10lC; Sun, 17 Mar 2024 11:56:41 +0000 (UTC) (envelope-from dsl@FreeBSD.org) References: <45965774-5534-s0o7-173n-ssq2s1330276@yvfgf.mnoonqbm.arg> User-agent: mu4e 1.8.13; emacs 29.2 From: Dmitry Salychev To: Warner Losh , "Bjoern A. Zeeb" Cc: freebsd-arm@freebsd.org Subject: Re: connect a "loose" device to a OFW/FDT node (and then use mii_fdt)? Date: Sun, 17 Mar 2024 11:27:39 +0100 In-reply-to: Message-ID: <86msqx6phk.fsf@peasant.tower.home> 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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=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 writes: > On Tue, Feb 27, 2024 at 1:40=E2=80=AFPM Bjoern A. Zeeb 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