From nobody Tue Feb 27 21:01:28 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 4TkqfZ37jGz5CQYB for ; Tue, 27 Feb 2024 21:01:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 4TkqfY6pWpz44Mm for ; Tue, 27 Feb 2024 21:01:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-512d19e2cb8so7013080e87.0 for ; Tue, 27 Feb 2024 13:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1709067700; x=1709672500; 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=iYqJaBXChS7xrax5en+dOkLtZ/Q2y0PF0pcRT5WXx7o=; b=Wuv/8T0WDE1PV53om/HPs89rcLpGRt1PizPnRU6PJ/JXqcb/Ji7t/CYSI0ecsSdiJB 1Pz+5KL1z64H+fUz9/abLlH3FvG8QytOQZu5/c/os0pc3XlwCZ0Qg1mTJnk5LT59v0qI sqdmxQHuhBvEPkOQiJdq8JtVnhxCaq+iScTHEIIFEc57IWChda5X+eVmsERVogvIcE3P WlJU3UpgGm0KLupIPhNdAXkeBaPtOWskKcckcCgIBiFAK0Y8tIIAVMnCmt/Qwp6sOIi3 w2PxUhUGCvlJyMF3ByNxWDysAKN+n3yiU8YbrAbjG9lcIe0gcFownxI33X3f6Eql9T4l UMhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709067700; x=1709672500; 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=iYqJaBXChS7xrax5en+dOkLtZ/Q2y0PF0pcRT5WXx7o=; b=xTpwwnvqrUyOp0mNLEm8Pomub5Hd0Fjr8RwTrGI9pUujzuID9T6vGA99QvkDgqf8no 0gWfHqDmCVo8qKfieQNri1cG5Ctqs+to3HAgzpsJnVIQp0BZdaIiW1Q5Y9UzkBgJ3iO9 f2hgmpXpaCBSdGa7lnES79P8VSgJ7q/KFk5zpHQxfvzegOx0sPMR22iPR2TeAVx7ejkp DhGFZ7LqT8kxK0G8Qy3rFkTe1CuyaLeAkDZ3Xt2wi67VTP1IPjMsBuYC47sewwYmxQkb jSDgdJp35/ApZEyT+3BR0l4yl7DOUycrkE2iUUw2Y24yaXL5VnNZy4sDepZ6GQcq66dV piTw== X-Gm-Message-State: AOJu0YyTvm0c8n0/mJ6H+2OXYaU+3Ktmq2hz989FSLYHuAovOqpzdV8x KfHBzeXgak1tmzIVZMqMca/PodIvRvVRPqvwxuVdPB2TjGY+hwP/LGRbdbmQRVoGb/1nTJ2bQz9 JJCsf+u9G+8INjbnKUlpfu2bm8drK2hr7fhg0Ps7OTTD5OO9O3TY= X-Google-Smtp-Source: AGHT+IEljB+bMPP6dp8CaC2UDnUxX/bDQQICZp39Km88wjs5I3bV0n9dcqg/hV2fGFJFsPtN+Q1ug1zDIXHuoZ3W3dQ= X-Received: by 2002:a05:6512:2523:b0:512:d8ad:b454 with SMTP id be35-20020a056512252300b00512d8adb454mr8721113lfb.61.1709067700270; Tue, 27 Feb 2024 13:01:40 -0800 (PST) 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> In-Reply-To: <45965774-5534-s0o7-173n-ssq2s1330276@yvfgf.mnoonqbm.arg> From: Warner Losh Date: Tue, 27 Feb 2024 14:01:28 -0700 Message-ID: Subject: Re: connect a "loose" device to a OFW/FDT node (and then use mii_fdt)? To: "Bjoern A. Zeeb" Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002c0ef1061263559b" 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: 4TkqfY6pWpz44Mm --0000000000002c0ef1061263559b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? > 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 --0000000000002c0ef1061263559b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 27, 2024 at 1:40=E2=80=AF= PM Bjoern A. Zeeb <bze= eb-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?
=C2=A0
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 i= ts 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 d= o what's normally a parent/child relationship in add-in cards via a pro= xy. From what you described below, it looks like that's what's goin= g on here, but I could be mistaken.
=C2=A0
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 nod= e in FDT
(continuing the "tree" there) and then use mii_fdt to attach (doi= ng
all the PHY stuff and references)?

You&= #39;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:

=C2=A0 X (ofw/fdt/simplebus node/device)
=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 d= evice is just another bus. It will have whatever children are proper for th= at 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+----- mac dev (in FDT but created as child of &= #39;interim dev' and not out of ofw/fdt/simplebus)

Wouldn't there be a PHANDLE or similar reference then p= ointing to this node in the tree?

But regardless, = you could create any device you want as a child of X, though in this case i= t is a little weird if the mac doesn't belong to something else that wo= uld be a simple bus or a simple bus super 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 +---- miibus(_fdt i= f 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+------ PHY

Usually the no= n-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 dr= iver. One could model it the way you are saying, but that's not a requi= rement. We've had several of these come up over the years since many So= Cs have direct control of the MII bus not through resources owned by the NI= C as is often the case with add-in cards.

So the q= uestion would become, is that the real situation here (in which case you= 9;d need to proxie=C2=A0messages between the NIC and PHY) or is it somethin= g else?

I can't recall if we have drivers in t= he 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 t= o 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 code= d.

Warner
--0000000000002c0ef1061263559b--