Re: svn commit: r334880 - head/sys/dev/vnic
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 +, 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 ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
On Sun, Jul 08, 2018 at 10:23:52AM -0600, Warner Losh wrote:
> On Sun, Jul 8, 2018 at 10:14 AM, Mark Johnston wrote:
> > Being unfamiliar with FDT, could I ask you to explain how the code could
> > be using phandles to find the PHYs?
> >
>
> Allwinner provides a good example, and says it in code better than I could
> quickly summarize:
>
> static phandle_t
> awg_get_phy_node(device_t dev)
> {
> phandle_t node;
> pcell_t phy_handle;
>
> node = ofw_bus_get_node(dev);
> if (OF_getencprop(node, "phy-handle", (void *)_handle,
> sizeof(phy_handle)) <= 0)
> return (0);
>
> return (OF_node_from_xref(phy_handle));
> }
I don't see how this can help in the fallback case where the PHY mode
isn't encoded anywhere except in the device name. In this case the
nodes referred to by the phy-handle properties look like this:
mdio@87e005003800 {
compatible = "cavium,thunder-8890-mdio";
#address-cells = <0x1>;
#size-cells = <0x0>;
reg = <0x87e0 0x5003800 0x0 0x30>;
xfi@0 {
reg = <0x0>;
compatible = "cortina,cs4223-slice";
linux,phandle = <0x75>;
phandle = <0x75>;
};
xfi@1 {
reg = <0x1>;
compatible = "cortina,cs4223-slice";
linux,phandle = <0x76>;
phandle = <0x76>;
};
};
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
On Sun, Jul 8, 2018 at 10:14 AM, 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 +, 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?
>
Allwinner provides a good example, and says it in code better than I could
quickly summarize:
static phandle_t
awg_get_phy_node(device_t dev)
{
phandle_t node;
pcell_t phy_handle;
node = ofw_bus_get_node(dev);
if (OF_getencprop(node, "phy-handle", (void *)_handle,
sizeof(phy_handle)) <= 0)
return (0);
return (OF_node_from_xref(phy_handle));
}
Warner
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
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 +, 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? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
> > ofwdump isn't very useful, you'll get much nicer output with: > > sysctl -b hw.fdt.dtb | dtc -I dtb -O dts >somefile.dts > > BTW, the whole idea of searching for a phy by walking the node > hierarchy doing string comparisons on node names sounds pretty > antithetical to the whole design of fdt data. Are these nodes not > properly cross-linked with phandles? > > -- Ian > Hrm ... this seems broken on these thundex machines. # sysctl -b hw.fdt.dtb | dtc -I dtb -O dts Error: property check failed, while checking node: / /soc @0 /pci @8480, [-Wtype-compatible] I dropped the output of the sysctl -b to: https://people.freebsd.org/~sbruno/thunderx_dtb.bin sean signature.asc Description: OpenPGP digital signature
Re: svn commit: r334880 - head/sys/dev/vnic
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 +, 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). Warner ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
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 +, 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 sean signature.asc Description: OpenPGP digital signature
Re: svn commit: r334880 - head/sys/dev/vnic
On Sun, 2018-07-08 at 11:26 -0400, 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 +, 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? > ofwdump isn't very useful, you'll get much nicer output with: sysctl -b hw.fdt.dtb | dtc -I dtb -O dts >somefile.dts BTW, the whole idea of searching for a phy by walking the node hierarchy doing string comparisons on node names sounds pretty antithetical to the whole design of fdt data. Are these nodes not properly cross-linked with phandles? -- Ian ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
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 +, 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? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r334880 - head/sys/dev/vnic
On 07/07/18 11:43, Mark Johnston wrote: > On Sat, Jun 09, 2018 at 02:47:49PM +, 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? sean signature.asc Description: OpenPGP digital signature
Re: svn commit: r334880 - head/sys/dev/vnic
On Sat, Jun 09, 2018 at 02:47:49PM +, 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. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r334880 - head/sys/dev/vnic
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
Modified:
head/sys/dev/vnic/thunder_bgx_fdt.c
Modified: head/sys/dev/vnic/thunder_bgx_fdt.c
==
--- head/sys/dev/vnic/thunder_bgx_fdt.c Sat Jun 9 14:26:30 2018
(r334879)
+++ head/sys/dev/vnic/thunder_bgx_fdt.c Sat Jun 9 14:47:49 2018
(r334880)
@@ -93,44 +93,44 @@ bgx_fdt_phy_mode_match(struct bgx *bgx, char *qlm_mode
switch (bgx->qlm_mode) {
case QLM_MODE_SGMII:
type = "sgmii";
- sz = sizeof("sgmii") - 1;
+ sz = sizeof("sgmii");
offset = size - sz;
break;
case QLM_MODE_XAUI_1X4:
type = "xaui";
- sz = sizeof("xaui") - 1;
+ sz = sizeof("xaui");
offset = size - sz;
if (offset < 0)
return (FALSE);
if (strncmp(_mode[offset], type, sz) == 0)
return (TRUE);
type = "dxaui";
- sz = sizeof("dxaui") - 1;
+ sz = sizeof("dxaui");
offset = size - sz;
break;
case QLM_MODE_RXAUI_2X2:
type = "raui";
- sz = sizeof("raui") - 1;
+ sz = sizeof("raui");
offset = size - sz;
break;
case QLM_MODE_XFI_4X1:
type = "xfi";
- sz = sizeof("xfi") - 1;
+ sz = sizeof("xfi");
offset = size - sz;
break;
case QLM_MODE_XLAUI_1X4:
type = "xlaui";
- sz = sizeof("xlaui") - 1;
+ sz = sizeof("xlaui");
offset = size - sz;
break;
case QLM_MODE_10G_KR_4X1:
type = "xfi-10g-kr";
- sz = sizeof("xfi-10g-kr") - 1;
+ sz = sizeof("xfi-10g-kr");
offset = size - sz;
break;
case QLM_MODE_40G_KR4_1X4:
type = "xlaui-40g-kr";
- sz = sizeof("xlaui-40g-kr") - 1;
+ sz = sizeof("xlaui-40g-kr");
offset = size - sz;
break;
default:
@@ -155,37 +155,37 @@ bgx_fdt_phy_name_match(struct bgx *bgx, char *phy_name
switch (bgx->qlm_mode) {
case QLM_MODE_SGMII:
type = "sgmii";
- sz = sizeof("sgmii") - 1;
+ sz = sizeof("sgmii");
break;
case QLM_MODE_XAUI_1X4:
type = "xaui";
- sz = sizeof("xaui") - 1;
+ sz = sizeof("xaui");
if (sz < size)
return (FALSE);
if (strncmp(phy_name, type, sz) == 0)
return (TRUE);
type = "dxaui";
- sz = sizeof("dxaui") - 1;
+ sz = sizeof("dxaui");
break;
case QLM_MODE_RXAUI_2X2:
type = "raui";
- sz = sizeof("raui") - 1;
+ sz = sizeof("raui");
break;
case QLM_MODE_XFI_4X1:
type = "xfi";
- sz = sizeof("xfi") - 1;
+ sz = sizeof("xfi");
break;
case QLM_MODE_XLAUI_1X4:
type = "xlaui";
- sz = sizeof("xlaui") - 1;
+ sz = sizeof("xlaui");
break;
case QLM_MODE_10G_KR_4X1:
type = "xfi-10g-kr";
- sz = sizeof("xfi-10g-kr") - 1;
+ sz = sizeof("xfi-10g-kr");
break;
case QLM_MODE_40G_KR4_1X4:
type = "xlaui-40g-kr";
- sz = sizeof("xlaui-40g-kr") - 1;
+ sz = sizeof("xlaui-40g-kr");
break;
default:
return (FALSE);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
