All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: No traffic with Marvell switch and latest linux-next
Date: Sun, 24 Feb 2019 18:28:48 +0100	[thread overview]
Message-ID: <20190224172848.GI26626@lunn.ch> (raw)
In-Reply-To: <20190224153125.f2n3xfjyjswd7ioa@shell.armlinux.org.uk>

On Sun, Feb 24, 2019 at 03:31:26PM +0000, Russell King - ARM Linux admin wrote:
> On Sun, Feb 24, 2019 at 12:42:35AM +0100, Andrew Lunn wrote:
> > Looking forward, at some point we are going to have to make fixed-link
> > support higher speeds. That probably means we need a swphy-c45 which
> > emulates the standard registers for 2.5G, 5G and 10G. At that point
> > genphy will not work...
> 
> Do we _need_ to emulate Clause 45 PHYs?

Hi Russell

One use case would be a mv88e6390X port 9 or 10 connected to a SoC
which can only do 2.5G.

We have defined that DSA drivers should configure CPU and DSA ports to
their maximum speed. So if port 9 or 10 is used, it should be
configured to 10G.

We then need some way to reconfigure the MAC to a slower speed.

We need to do this with ZII boards. We do this with:

                                        port@0 {
                                                reg = <0>;
                                                label = "cpu";
                                                ethernet = <&fec1>;

                                                fixed-link {
                                                        speed = <100>;
                                                        full-duplex;
                                                };
                                        };

The FEC can only do 100Mbs, but the switch defaults to 1G. So the
fixed link it used to tell the switch MAC to use 100/Full.

In the example of the 6390X, we would want to set the link speed to
2500, which we cannot do at the moment. Either we need fixed-link to
support higher speeds, or we need a different mechanism.

We also have a similar issue on the SoC side. The FEC has no PHY
connected to it. It needs to be told what speed to do:

&fec1 {
        phy-mode = "rmii";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_fec1>;
        status = "okay";

        fixed-link {
                   speed = <100>;
                   full-duplex;
        };

In the case of a SoC with an interface which can do 2.5G, you need to
tell it to do 2.5G. Ideally we want a mechanism that allows a MAC to
'see' a PHY operating at 2.5G using the standard phylib/phylink API.

In the past this has been achieved with an emulated PHY. But so long
as the phydev/phylink structure has the correct values, it does not
matter how they get those values.

      Andrew

  reply	other threads:[~2019-02-24 17:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-17 15:34 No traffic with Marvell switch and latest linux-next Heiner Kallweit
2019-02-17 15:40 ` Russell King - ARM Linux admin
2019-02-17 15:50   ` Heiner Kallweit
2019-02-17 16:40     ` Heiner Kallweit
2019-02-17 16:57       ` Andrew Lunn
2019-02-17 17:06         ` Heiner Kallweit
2019-02-17 17:10           ` Andrew Lunn
2019-02-18 18:16             ` Heiner Kallweit
2019-02-18 18:21               ` Andrew Lunn
2019-02-23 21:48                 ` Heiner Kallweit
2019-02-23 23:42                   ` Andrew Lunn
2019-02-24  9:10                     ` Heiner Kallweit
2019-02-24 15:04                       ` Andrew Lunn
2019-02-24 15:15                         ` Russell King - ARM Linux admin
2019-02-24 15:28                           ` Heiner Kallweit
2019-02-24 15:34                             ` Russell King - ARM Linux admin
2019-02-24 15:39                               ` Heiner Kallweit
2019-02-24 15:49                                 ` Russell King - ARM Linux admin
2019-02-24 16:32                                   ` Florian Fainelli
2019-02-24 17:04                                     ` Andrew Lunn
2019-02-24 21:26                                       ` Florian Fainelli
2019-02-24 21:42                                         ` Heiner Kallweit
2019-02-24 15:31                     ` Russell King - ARM Linux admin
2019-02-24 17:28                       ` Andrew Lunn [this message]
2019-02-24 19:41                         ` Russell King - ARM Linux admin
2019-02-23 23:55                   ` Florian Fainelli
2019-02-17 15:45 ` Andrew Lunn
2019-02-17 15:48   ` Heiner Kallweit
2019-02-17 15:57     ` Andrew Lunn
2019-02-17 16:01       ` Heiner Kallweit
2019-02-17 15:51 ` Andrew Lunn
2019-02-17 15:55   ` Heiner Kallweit

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=20190224172848.GI26626@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.