netdev - Re: [PATCH net-next 4/9] net: dsa: Allow configuration of CPU & DSA port speeds/duplex

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]

Message-ID: <55DA1340.9080604@gmail.com>
Date:	Sun, 23 Aug 2015 11:38:56 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 4/9] net: dsa: Allow configuration of CPU & DSA
 port speeds/duplex

Le 08/23/15 02:46, Andrew Lunn a écrit :
> By default, DSA and CPU ports are configured to the maximum speed the
> switch supports. However there can be use cases where the peer devices
> port is slower. Allow a fixed-link property to be used with the DSA
> and CPU port in the device tree, and use this information to configure
> the port.
> 
> Signed-off-by: Andrew Lunn <andrew@...n.ch>
> ---
>  net/dsa/dsa.c | 37 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
> index 053eb2b8e682..afff17341b73 100644
> --- a/net/dsa/dsa.c
> +++ b/net/dsa/dsa.c
> @@ -176,6 +176,35 @@ __ATTRIBUTE_GROUPS(dsa_hwmon);
>  #endif /* CONFIG_NET_DSA_HWMON */
>  
>  /* basic switch operations **************************************************/
> +static int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct net_device *master)
> +{
> +	struct dsa_chip_data *cd = ds->pd;
> +	struct device_node *port_dn;
> +	struct phy_device *phydev;
> +	int ret, port;
> +
> +	for (port = 0; port < DSA_MAX_PORTS; port++) {
> +		if (!(dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)))
> +			continue;
> +
> +		port_dn = cd->port_dn[port];
> +		if (of_phy_is_fixed_link(port_dn)) {
> +			ret = of_phy_register_fixed_link(port_dn);
> +			if (ret) {
> +				netdev_err(master,
> +					   "failed to register fixed PHY\n");
> +				return ret;
> +			}
> +			phydev = of_phy_find_device(port_dn);
> +			genphy_config_init(phydev);
> +			genphy_read_status(phydev);
> +			if (ds->drv->adjust_link)
> +				ds->drv->adjust_link(ds, port, phydev);

This kind of hack here because what you really need is just the link
parameters, but you cannot obtain such information without first
configuring the PHY up to a certain point in genphy_config_init(), and
then have genphy_read_status() copy these values in your phydev structure.

Maybe we should really consider something like this after all:

https://lkml.org/lkml/2015/8/5/490

Or maybe, we should really introduce this "cpu" network device after all
with a dropping xmit function, such that we get ethtool counters to work
on it, and we can also attach it to a PHY device to configure link
parameters?
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html