From nobody Tue Dec 14 11:15:06 2021 X-Original-To: freebsd-hackers@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 2476618E1AD0 for ; Tue, 14 Dec 2021 11:15:17 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCwlR73DMz3kYy for ; Tue, 14 Dec 2021 11:15:15 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Tue, 14 Dec 2021 12:15:07 +0100 id 00DADC7E.61B87CBB.0000603A Date: Tue, 14 Dec 2021 12:15:06 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Two devices created for one block in device tree? Message-ID: <20211214121506.34c7f96b@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git299 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCwlR73DMz3kYy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-0.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[1.50.218.176:email,0.0.0.0:email,0.0.0.1:email,1.50.226.128:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.988]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi, is it possible to attach two different devices for one device description in device tree, with some order being guaranted, maybe one device in a pass? To be clear, I am trying to solve problem with PHY being attached to MAC being initialized later. I have a board with two MACs and two PHYs. There is a data connection from MAC to PHY - SGMII, one to one, and there is another connection, MDIO, with a bus controller via second MAC. In a device tree, it looks like this: ethernet@20110000 { status = "okay"; phy-handle = <0x00000010>; }; ethernet@20112000 { status = "okay"; phy-handle = <0x00000011>; ethernet-phy@0 { phandle = <0x00000010>; }; ethernet-phy@1 { phandle = <0x00000011>; }; }; (only some properties written here, just to illustrate the case) So it is basically the same as Routerstation or Routerstation Pro using if_arge interface. I understand the concept of mdio/miiproxy used here, but those boards' configs uses hints, different mechanism, not FDT/DTS. However, the problem is the same - on first pass through device tree, MDIO device is being created and initialized, then PHYs attached are being probed, attached and initialized, and then, in second pass, ethernet inteface is being created, initialized and configured to use PHY already found as prescribed. I searched in recent source tree for inspiration, but there are only three devices with something similar - if_arge.c in sys/mips/atheros, if_are.c in sys/mips/atheros/ar531x, and if_rt.c in sys/dev/rt. The last one, if_rt.c, uses two compatible strings to differentiate MAC and MDIO controllers, maybe they are implemented independently, I don't know, I did not found DTS using it. The rest uses hints, as already mentioned. For now, I see no working method for this scenario. The device in my case is Cadence GEM, MII readreg/writereg function are already there. All I need is just create a proxy for first ethernet, which should use those function accessing MDIO controller for second ethernet. In single pass scenario, this could not work because MDIO controller is not yet working when first ethernet is being initialized. Trying to use multi pass scenario, if I attach MDIO controller on first pass, MAC controller is not attached on second pass, because there is already driver attached. Could anybody provide any hint to me? It could be something obvious I just don't see, also one more complication is the code should be compiled conditionally, maybe using 'options CGEM_MDIO' in config file (just as if_arge and if_are do), because there are other boards with no need for mdio/miiproxy, I'd prefer to use simpler code for this case. Regards, Milan