From owner-svn-src-all@freebsd.org Sun Jul 8 16:45:55 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84CE7103B166 for ; Sun, 8 Jul 2018 16:45:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFC77E067 for ; Sun, 8 Jul 2018 16:45:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 5fab1e09-82ce-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 5fab1e09-82ce-11e8-8837-614b7c574d04; Sun, 08 Jul 2018 16:45:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w68Gjp7L031549; Sun, 8 Jul 2018 10:45:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531068351.1336.15.camel@freebsd.org> Subject: Re: svn commit: r334880 - head/sys/dev/vnic From: Ian Lepore To: Mark Johnston , Warner Losh Cc: Sean Bruno , Andrew Turner , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sun, 08 Jul 2018 10:45:51 -0600 In-Reply-To: <20180708161415.GD18193@pesky> References: <201806091447.w59ElnpU026396@repo.freebsd.org> <20180707174351.GA95934@pesky> <20180708152621.GB18193@pesky> <5483bcd6-f3bc-8b78-ee51-3bf3c2a1c2da@freebsd.org> <20180708161415.GD18193@pesky> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2018 16:45:55 -0000 On Sun, 2018-07-08 at 12:14 -0400, Mark Johnston wrote: > On Sun, Jul 08, 2018 at 09:58:35AM -0600, Warner Losh wrote: > > > > On Sun, Jul 8, 2018 at 9:55 AM, Sean Bruno > > wrote: > > > > > > > > > > > > > > On 07/08/18 09:26, Mark Johnston wrote: > > > > > > > > On Sun, Jul 08, 2018 at 09:10:27AM -0600, Sean Bruno wrote: > > > > > > > > > > > > > > > > > > > > On 07/07/18 11:43, Mark Johnston wrote: > > > > > > > > > > > > On Sat, Jun 09, 2018 at 02:47:49PM +0000, Andrew Turner > > > > > > wrote: > > > > > > > > > > > > > > Author: andrew > > > > > > > Date: Sat Jun  9 14:47:49 2018 > > > > > > > New Revision: 334880 > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/334880 > > > > > > > > > > > > > > Log: > > > > > > >   In the ThunderX BGX network driver we were skipping the > > > > > > > NULL > > > terminator > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   when parsing the phy type, however this is included in > > > > > > > the length > > > returned > > > > > > > > > > > > > > > > > > > > > > > > > > > > >   by OF_getprop. To fix this stop ignoring the > > > > > > > terminator. > > > > > > > > > > > > > >   PR:              228828 > > > > > > >   Reported by:     sbruno > > > > > > >   Sponsored by:    DARPA, AFRL > > > > > > This seems to break vnic on packet.net ThunderXs.  In > > > > > > particular, VF > > > > > > creation fails.  It seems the problem in my case is that > > > > > > there are > > > > > > multiple PHY devices in the device tree, e.g., xfi@0, xfi@1 > > > > > > .  With > > > this > > > > > > > > > > > > > > > > > > > > > change, bgx_fdt_phy_name_match() fails to match against any > > > > > > device > > > > > > containing a unit address in the node name. > > > > > > > > > > > > > > > > Huh ... this was *required* to get the ThunderXs we have in > > > > > the FreeBSD > > > > > cluster to work at all.  o.0 > > > > > > > > > > I guess "someone" needs to contact "someone" to figure out > > > > > which is > > > > > correct or we need to replace our FreeBSD cluster machines > > > > > with ones > > > > > that work like the packet.net machines? > > > > I think the current code works fine if there's only one PHY > > > > device, so > > > > my problem is probably just the result of having a different > > > > hardware > > > > setup.  We can probably fix the code to handle both > > > > cases.  Could you > > > > mail me the output of "ofwdump -ap" from the cluster machine? > > > > > > > > > > > > > > I dropped the output here: > > > https://people.freebsd.org/~sbruno/ofwdump.txt > > > > Ian's method is better. But Ian's question is better: are there not > > phandles to find this stuff? Names in FDT are kinda meaningless > > most of the > > time (I say kinda here to gloss over a laundry list of exceptions > > that PHY > > finding typically does not fall into). > Sean's output shows why the current code works for him.  In my case > the > bgx subnodes don't contain a qlm-mode property, so we're falling back > to > name matching: > > Node 0x891c: bgx0 >   #address-cells: >     00 00 00 01  >   #size-cells: >     00 00 00 00  >   reg: >     00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >   Node 0x8ad8: xfi@0 >     reg: >       00 00 00 00  >     local-mac-address: >       fc 15 b4 97 48 b7  >     phy-handle: >       00 00 00 75  >   Node 0x8b34: xfi@1 >     reg: >       00 00 00 01  >     local-mac-address: >       fc 15 b4 97 48 b8  >     phy-handle: >       00 00 00 76  > > Being unfamiliar with FDT, could I ask you to explain how the code > could > be using phandles to find the PHYs? > In Sean's output, the phy nodes had multiple strings encoded in their qlm-mode properties (note the embedded 0 about 6-8 bytes in). Based on pure guesswork (because I can't find published fdt-bindings docs for any of this stuff), maybe the phy supports multiple modes, so the mac node has to have a property to say which mode is used. It may be that the property in the mac node is optional when the phy node only lists one qlm-mode, and maybe in that case the thing to do is retrieve the property from the phy node after using the xref-phandle to get to that node. -- Ian