[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190125202535.50d5b402@nic.cz>
Date: Fri, 25 Jan 2019 20:25:35 +0100
From: Marek Behun <marek.behun@....cz>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to
1000BaseX only on 6390X
On Fri, 25 Jan 2019 10:48:38 -0800
Florian Fainelli <f.fainelli@...il.com> wrote:
> On 1/24/19 11:39 AM, Marek Behun wrote:
> > On Thu, 24 Jan 2019 11:27:54 -0800
> > Florian Fainelli <f.fainelli@...il.com> wrote:
> >
> >> On 1/24/19 11:24 AM, Marek Behun wrote:
> >>> On Thu, 24 Jan 2019 19:11:59 +0100
> >>> Andrew Lunn <andrew@...n.ch> wrote:
> >>>
> >>>> On Thu, Jan 24, 2019 at 07:04:51PM +0100, Marek Behun wrote:
> >>>>> What properties does the cpu port node need to contain to force
> >>>>> it? phy-mode = "2500base-x"; is not enough.
> >>>>
> >>>> Hi Marek
> >>>>
> >>>> For DSA ports we have:
> >>>>
> >>>> phy-mode =
> >>>> "rgmii-txid"; fixed-link {
> >>>> speed =
> >>>> <1000>; full-duplex;
> >>>> };
> >>>>
> >>>> See dsa_port_fixed_link_register_of()
> >>>>
> >>>> Andrew
> >>>
> >>> Hi Andrew,
> >>> the configuration
> >>> phy-mode = "2500base-x";
> >>> fixed-link {
> >>> speed = <2500>;
> >>> full-duplex;
> >>> };
> >>> does not work, because swphy does not support speed=2500 (only 10,
> >>> 100 and 1000).
> >>> managed = "in-band-status";
> >>> does not work either.
> >>>
> >>> If I use speed = <1000>, then the swphy is created correctly,
> >>> cmode is set correctly to 2500base-x, but speed register on the
> >>> port is set to 1000, and the connection does not work.
> >>>
> >>> The easiest way would probably be to implement swphy to support
> >>> speed 2500. But I don't know what values should the simulated PHY
> >>> registers contain...
> >>>
> >>> The function dsa_port_fixed_link_register_of creates this phy
> >>> device, adjusts the link and then calls
> >>> put_device(&phydev->mdio.dev); Does this mean that the phy device
> >>> is immediately destroyed?
> >>
> >> Yes, we should actually migrate that code over to PHYLINK, because
> >> in PHYLINK the fixed links don't require creating a phy_device
> >> instance. This is something that has a potential of breaking a lot
> >> of people, so I have not really started doing it just yet :)
> >
> > Can't then this patch be applied so that Turris Mox will work
> > again? At least till the cpu/dsa port connection is converted to
> > phylink.
>
> How about the following hack until we can support netdev less PHYLINK
> instances while having the Device Tree being corrected to have the
> correct phy-mode = "2500base-x" property since we will need it for
> PHYLINK on CPU/DSA ports later on:
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index 2d7e01b23572..9ea052c30b68 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -359,6 +359,14 @@ static int dsa_port_fixed_link_register_of(struct
> dsa_port *dp)
> if (mode < 0)
> mode = PHY_INTERFACE_MODE_NA;
> phydev->interface = mode;
> + switch (mode) {
> + case PHY_INTERFACE_MODE_2500BASEX:
> + phydev->speed = SPEED_2500;
> + break;
> + case PHY_INTERFACE_MODE_10GKR:
> + phydev->speed = SPEED_10000;
> + break;
> + }
>
> genphy_config_init(phydev);
> genphy_read_status(phydev);
But in the dts there would still have to be speed=<1000>; otherwise
swphy will fail...
Powered by blists - more mailing lists