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

Powered by Openwall GNU/*/Linux Powered by OpenVZ