linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: andrew@lunn.ch, vivien.didelot@gmail.com, f.fainelli@gmail.com,
	davem@davemloft.net, kuba@kernel.org, robh+dt@kernel.org,
	claudiu.manoil@nxp.com, alexandre.belloni@bootlin.com,
	UNGLinuxDriver@microchip.com, hkallweit1@gmail.com,
	linux@armlinux.org.uk, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 net-next 10/10] docs: devicetree: add documentation for the VSC7512 SPI device
Date: Sat, 14 Aug 2021 11:40:40 -0700	[thread overview]
Message-ID: <20210814184040.GD3244288@euler> (raw)
In-Reply-To: <20210814114721.ncxi6xwykdi4bfqy@skbuf>

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...


  reply	other threads:[~2021-08-14 18:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-14  2:49 [RFC PATCH v3 net-next 00/10] add support for VSC75XX control over SPI Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 01/10] net: dsa: ocelot: remove unnecessary pci_bar variables Colin Foster
2021-08-14 11:07   ` Vladimir Oltean
2021-08-14 16:26     ` Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 02/10] net: mdio: mscc-miim: convert to a regmap implementation Colin Foster
2021-08-14 11:03   ` Vladimir Oltean
2021-08-20 16:53     ` Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 03/10] net: dsa: ocelot: felix: switch to mdio-mscc-miim driver for indirect mdio access Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 04/10] net: dsa: ocelot: felix: Remove requirement for PCS in felix devices Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 05/10] net: dsa: ocelot: felix: add interface for custom regmaps Colin Foster
2021-08-14  2:49 ` [RFC PATCH v3 net-next 06/10] net: mscc: ocelot: split register definitions to a separate file Colin Foster
2021-08-14 11:15   ` Vladimir Oltean
2021-08-14 16:33     ` Colin Foster
2021-08-14 16:56   ` Alexandre Belloni
2021-08-14  2:50 ` [RFC PATCH v3 net-next 07/10] net: mscc: ocelot: expose ocelot wm functions Colin Foster
2021-08-14 11:17   ` Vladimir Oltean
2021-08-14 16:36     ` Colin Foster
2021-08-14  2:50 ` [RFC PATCH v3 net-next 08/10] net: mscc: ocelot: felix: add ability to enable a CPU / NPI port Colin Foster
2021-08-14  2:50 ` [RFC PATCH v3 net-next 09/10] net: dsa: ocelot: felix: add support for VSC75XX control over SPI Colin Foster
2021-08-14 11:43   ` Vladimir Oltean
2021-08-14 12:02     ` Vladimir Oltean
2021-08-15 19:10       ` Colin Foster
2021-08-15 20:41       ` Colin Foster
2021-08-15 23:14         ` Russell King (Oracle)
2021-08-15 23:27           ` Colin Foster
2021-08-16  0:05             ` Russell King (Oracle)
2021-08-17  9:41         ` Vladimir Oltean
2021-08-15 21:35       ` Russell King (Oracle)
2021-08-14  2:50 ` [RFC PATCH v3 net-next 10/10] docs: devicetree: add documentation for the VSC7512 SPI device Colin Foster
2021-08-14 11:47   ` Vladimir Oltean
2021-08-14 18:40     ` Colin Foster [this message]
2021-08-14 19:08       ` Vladimir Oltean
2021-08-14 23:41         ` Colin Foster
2021-08-15  0:00           ` Vladimir Oltean
2021-08-15  1:08             ` Colin Foster
2021-08-17 22:08   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210814184040.GD3244288@euler \
    --to=colin.foster@in-advantage.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).