netdev - Re: [net-next 07/15] ixgbe: fix SFF data dumps of SFP+ modules

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1375434517.24371.24.camel@deadeye.wl.decadent.org.uk>
Date:	Fri, 2 Aug 2013 11:08:37 +0200
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
CC:	<davem@...emloft.net>, Emil Tantilov <emil.s.tantilov@...el.com>,
	<netdev@...r.kernel.org>, <gospo@...hat.com>, <sassmann@...hat.com>
Subject: Re: [net-next 07/15] ixgbe: fix SFF data dumps of SFP+ modules

On Mon, 2013-07-29 at 05:52 -0700, Jeff Kirsher wrote:
> From: Emil Tantilov <emil.s.tantilov@...el.com>
> 
> This patch fixes several issues with the previous implementation of the
> SFF data dump of SFP+ modules:
> 
> - removed the __IXGBE_READ_I2C flag - I2C access locking is handled in the
>   HW specific routines
> 
> - fixed the read loop to read data from ee->offset to ee->len
> 
> - the reads fail if __IXGBE_IN_SFP_INIT is set in the process - this is
>   needed because on some HW I2C operations can take long time and disrupt
>   the SFP and link detection process
> 
> Signed-off-by: Emil Tantilov <emil.s.tantilov@...el.com>
> Reported-by: Ben Hutchings <bhutchings@...arflare.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@...el.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
[...]
> @@ -2969,48 +2955,25 @@ static int ixgbe_get_module_eeprom(struct net_device *dev,
>  	int i = 0;
>  	int ret_val = 0;
>  
> -	/* ixgbe_get_module_info is called before this function in all
> -	 * cases, so we do not need any checks we already do above,
> -	 * and can trust ee->len to be a known value.
> -	 */
> +	if (ee->len == 0)
> +		return -EINVAL;
>  
> -	while (test_bit(__IXGBE_IN_SFP_INIT, &adapter->state))
> -		msleep(100);
> -	set_bit(__IXGBE_READ_I2C, &adapter->state);
> +	for (i = ee->offset; i < ee->len; i++) {

                               i < ee->offset + ee->len

> +		/* I2C reads can take long time */
> +		if (test_bit(__IXGBE_IN_SFP_INIT, &adapter->state))
> +			return -EBUSY;
>  
> -	/* Read the first block, SFF-8079 */
> -	for (i = 0; i < ETH_MODULE_SFF_8079_LEN; i++) {
> -		status = hw->phy.ops.read_i2c_eeprom(hw, i, &databyte);
> -		if (status != 0) {
> -			/* Error occured while reading module */
> +		if (i < ETH_MODULE_SFF_8079_LEN)
> +			status  = hw->phy.ops.read_i2c_eeprom(hw, i, &databyte);
> +		else
> +			status = hw->phy.ops.read_i2c_sff8472(hw, i, &databyte);
[...]
                                                     i - ETH_MODULE_SFF_8079_LEN ?

But this works anyway because the address is truncated to u8.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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