linux-kernel - Re: [RFC PATCH v3 net-next 10/10] docs: devicetree: add documentation for the VSC7512 SPI device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 14 Aug 2021 11:40:40 -0700
From:   Colin Foster <colin.foster@...advantage.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     andrew@...n.ch, vivien.didelot@...il.com, f.fainelli@...il.com,
        davem@...emloft.net, kuba@...nel.org, robh+dt@...nel.org,
        claudiu.manoil@....com, alexandre.belloni@...tlin.com,
        UNGLinuxDriver@...rochip.com, hkallweit1@...il.com,
        linux@...linux.org.uk, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 net-next 10/10] docs: devicetree: add
 documentation for the VSC7512 SPI device

On Sat, Aug 14, 2021 at 02:47:21PM +0300, Vladimir Oltean wrote:
> On Fri, Aug 13, 2021 at 07:50:03PM -0700, Colin Foster wrote:
> > +* phy_mode = "sgmii": on ports 0, 1, 2, 3
> 
> > +			port@0 {
> > +				reg = <0>;
> > +				ethernet = <&mac>;
> > +				phy-mode = "sgmii";
> > +
> > +				fixed-link {
> > +					speed = <100>;
> > +					full-duplex;
> > +				};
> > +			};
> 
> Your driver is unconditionally setting up the NPI port at gigabit and
> you claim it works, yet the device tree sees a 100Mbps fixed-link? Which
> one is right, what speed does the port operate at?

Good catch!

I made the change to ocelot_spi_vsc7512 yesterday to set it up as
gigabit, tested it, and it still works. Previously for my testing I'd
had it hard-coded to 100, because the Beaglebone I'm using only supports
100Mbps on eth0.

# phytool print swp1/0

ieee-phy: id:0x00070540

   ieee-phy: reg:BMCR(0x00) val:0x1040
      flags:          -reset -loopback .[1m+aneg-enable.[0m -power-down -isolate -aneg-restart -collision-test
      speed:          1000-half

   ieee-phy: reg:BMSR(0x01) val:0x796d
      capabilities:   -100-b4 .[1m+100-f.[0m .[1m+100-h.[0m .[1m+10-f.[0m .[1m+10-h.[0m -100-t2-f -100-t2-h
      flags:          .[1m+ext-status.[0m .[1m+aneg-complete.[0m -remote-fault .[1m+aneg-capable.[0m .[1m+link.[0m -jabber .[1m+ext-register.[0m

Of course I understand that "it works" is not the same as "it's correct"

What I wanted to accomplish was to use the speed parameter and set up
the link based on that. I looked through all the DSA drivers and
couldn't find anything that seems to do that. The closest thing I saw
was in mt7531_cpu_port_config where they set the speed to either 2500 or
1000 based on the interface. But nothing that I saw would explicitly set
the speed based on this parameter.

So I think there's something I'm missing. The fixed-link speed should apply to 
the CPU port on the switch (port@0)? Then eth0 can be manually set to a
specific speed, but if it doesn't match the fixed-link speed I'd be out
of luck? Or should an ip link or ethtool command to eth0 modify the
speeds of both sides of the connection? It feels like setting port@0 to
the fastest speed and letting it negotiate down to eth0 makes sense...

To ask the same question a different way:

I can currently run "ethtool -s eth0 speed 10 duplex full autoneg on" 
and the link at eth0 drops to 10Mbps. Pinging my desktop jumps from 
about 400us to about 600us when I do that.

Should I not be able to do that? It should be fixed at 100Mbps without
autoneg, end of story? Because in the current configuration it feels
like the fixed-link settings are more a suggestion than a rule...