netdev - Re: [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and 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: <567A90D9.9040204@cogentembedded.com>
Date:	Wed, 23 Dec 2015 15:17:29 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	zyjzyj2000@...il.com, jeffrey.t.kirsher@...el.com,
	jesse.brandeburg@...el.com, shannon.nelson@...el.com,
	carolyn.wyborny@...el.com, donald.c.skidmore@...el.com,
	bruce.w.allan@...el.com, john.ronciak@...el.com,
	mitch.a.williams@...el.com, intel-wired-lan@...ts.osuosl.org,
	netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net
Cc:	venkat.viswanathan@...driver.com, Boris.Shteinbock@...driver.com,
	Vincent.Bourg@...driver.com
Subject: Re: [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and
 getting speed and duplex

Hello.

On 12/23/2015 9:46 AM, zyjzyj2000@...il.com wrote:

> From: Zhu Yanjun <zyjzyj2000@...il.com>
>
> In X540 NIC, there is a time span between reporting "link on" and
> getting the speed and duplex. To a bonding driver in 802.3ad mode,
> this time span will make it not work well if the time span is big
> enough. The big time span will make bonding driver change the state of
> the slave device to up while the speed and duplex of the slave device
> can not be gotten. Later the bonding driver will not have change to
> get the speed and duplex of the slave device. The speed and duplex of
> the slave device are important to a bonding driver in 802.3ad mode.
>
> To 82599_SFP NIC and other kinds of NICs, this problem does
> not exist. As such, it is necessary for X540 to report"link on" when
> the link speed is not IXGBE_LINK_SPEED_UNKNOWN.
>
> Signed-off-by: Zhu Yanjun <zyjzyj2000@...il.com>
> ---
>   drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |   16 +++++++++++++++-
>   1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index aed8d02..cb9d310 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6479,7 +6479,21 @@ static void ixgbe_watchdog_link_is_up(struct ixgbe_adapter *adapter)
>   	       (flow_rx ? "RX" :
>   	       (flow_tx ? "TX" : "None"))));
>
> -	netif_carrier_on(netdev);
> +	/*
> +	 * In X540 NIC, there is a time span between reporting "link on"
> +	 * and getting the speed and duplex. To a bonding driver in 802.3ad
> +	 * mode, this time span will make it not work well if the time span
> +	 * is big enough. To 82599_SFP NIC and other kinds of NICs, this
> +	 * problem does not exist. As such, it is better for X540 to report
> +	 * "link on" when the link speed is not IXGBE_LINK_SPEED_UNKNOWN.
> +	 */
> +	if ((hw->mac.type == ixgbe_mac_X540) &&
> +	    (link_speed != IXGBE_LINK_SPEED_UNKNOWN)) {
> +		netif_carrier_on(netdev);
> +	} else {
> +		netif_carrier_on(netdev);
> +	}
> +

    {} not needed here. And you do the same thing regardless of whether your 
check succeeds or not, this doesn't make sense.

[...]

MBR, Sergei

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