[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR04MB4880BE4EA7B7C0A1EEA0A0D196DD0@VI1PR04MB4880.eurprd04.prod.outlook.com>
Date: Fri, 16 Nov 2018 09:32:19 +0000
From: Claudiu Manoil <claudiu.manoil@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: "David S . Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Alexandru Marginean <alexandru.marginean@....com>,
Catalin Horghidan <catalin.horghidan@....com>
Subject: RE: [PATCH net-next 1/4] enetc: Introduce basic PF and VF ENETC
ethernet drivers
>-----Original Message-----
>From: Andrew Lunn <andrew@...n.ch>
>Sent: Thursday, November 15, 2018 10:36 PM
>To: Claudiu Manoil <claudiu.manoil@....com>
>Cc: David S . Miller <davem@...emloft.net>; netdev@...r.kernel.org; linux-
>kernel@...r.kernel.org; Alexandru Marginean
><alexandru.marginean@....com>; Catalin Horghidan
><catalin.horghidan@....com>
>Subject: Re: [PATCH net-next 1/4] enetc: Introduce basic PF and VF ENETC
>ethernet drivers
>
>On Thu, Nov 15, 2018 at 06:13:53PM +0200, Claudiu Manoil wrote:
>> ENETC is a multi-port virtualized Ethernet controller supporting GbE
>> designs
>
>Hi Claudiu
>
>Do you mean 1GbE, or multigigabit? Do you have a SERDES between the MAC
>and the PHY? Could an SFP be connected?
>
Hi Andrew,
On the first chip to include enetc, LS1028A SoC, you have SGMII ports mostly but
there's also one RGMII port. Depending on phy type (board design) the SGMII ports
can also support 2.5G links. The first board available however, ls1028a-rdb, will only
feature 1G links. I think SFP phys could be supported in future board designs.
>> +static int enetc_of_get_phy(struct enetc_ndev_priv *priv) {
>> + struct device_node *np = priv->dev->of_node;
>> + int err;
>> +
>> + if (!np) {
>> + dev_err(priv->dev, "missing ENETC port node\n");
>> + return -ENODEV;
>> + }
>> +
>> + priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
>> + if (!priv->phy_node) {
>> + if (!of_phy_is_fixed_link(np)) {
>> + dev_err(priv->dev, "PHY not specified\n");
>> + return -ENODEV;
>> + }
>> +
>> + err = of_phy_register_fixed_link(np);
>> + if (err < 0) {
>> + dev_err(priv->dev, "fixed link registration failed\n");
>> + return err;
>> + }
>> +
>> + priv->phy_node = of_node_get(np);
>> + }
>> +
>> + priv->if_mode = of_get_phy_mode(np);
>> + if (priv->if_mode < 0) {
>> + dev_err(priv->dev, "missing phy type\n");
>> + of_node_put(priv->phy_node);
>> + if (of_phy_is_fixed_link(np))
>> + of_phy_deregister_fixed_link(np);
>> +
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>
>I asked the above questions because of this. Using phylink will simplify a lot of
>this. And it makes you future proof for faster speeds and handling the SERDES
>between the MAC and the PHY, and having an SFP, etc.
>
I know phylib has some limitations that are supposed to be addressed by phylink,
but I didn't figure out yet how phylink does that or whether it works on our designs
too. Last time I checked, only marvell had phylink integrated, and it sure doesn't
look as easy to integrate as phylib. I think the plan is that we can switch from phylib
to phylink when needed (once we figure it out), since phylib is less intrusive to integrate.
Until then, phylib should be good enough, at least for the ls1028a-rdb board which
doesn't feature SFPs nor 2.5G links.
Thanks,
Claudiu
Powered by blists - more mailing lists