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: <02a901d8f405$1c21a350$5464e9f0$@trustnetic.com>
Date:   Wed, 9 Nov 2022 14:32:58 +0800
From:   Jiawen Wu <jiawenwu@...stnetic.com>
To:     "'Andrew Lunn'" <andrew@...n.ch>,
        "'Mengyuan Lou'" <mengyuanlou@...-swift.com>
Cc:     <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 1/5] net: txgbe: Identify PHY and SFP module

On Wednesday, November 9, 2022 4:53 AM, Andrew Lunn wrote:
> > +/**
> > + *  txgbe_identify_sfp_module - Identifies SFP modules
> > + *  @hw: pointer to hardware structure
> > + *
> > + *  Searches for and identifies the SFP module and assigns appropriate PHY type.
> > + **/
> > +static int txgbe_identify_sfp_module(struct txgbe_hw *hw) {
> > +	u8 oui_bytes[3] = {0, 0, 0};
> > +	u8 comp_codes_10g = 0;
> > +	u8 comp_codes_1g = 0;
> > +	int status = -EFAULT;
> > +	u32 vendor_oui = 0;
> > +	u8 identifier = 0;
> > +	u8 cable_tech = 0;
> > +	u8 cable_spec = 0;
> > +
> > +	/* LAN ID is needed for I2C access */
> > +	txgbe_init_i2c(hw);
> > +
> > +	status = txgbe_read_i2c_eeprom(hw, TXGBE_SFF_IDENTIFIER, &identifier);
> > +	if (status != 0)
> > +		goto err_read_i2c_eeprom;
> > +
> > +	if (identifier != TXGBE_SFF_IDENTIFIER_SFP) {
> > +		hw->phy.type = txgbe_phy_sfp_unsupported;
> > +		status = -ENODEV;
> > +	} else {
> > +		status = txgbe_read_i2c_eeprom(hw, TXGBE_SFF_1GBE_COMP_CODES,
> > +					       &comp_codes_1g);
> > +		if (status != 0)
> > +			goto err_read_i2c_eeprom;
> > +
> > +		status = txgbe_read_i2c_eeprom(hw, TXGBE_SFF_10GBE_COMP_CODES,
> > +					       &comp_codes_10g);
> > +		if (status != 0)
> > +			goto err_read_i2c_eeprom;
> > +
> > +		status = txgbe_read_i2c_eeprom(hw, TXGBE_SFF_CABLE_TECHNOLOGY,
> > +					       &cable_tech);
> > +		if (status != 0)
> > +			goto err_read_i2c_eeprom;
> > +
> > +		 /* ID Module
> > +		  * =========
> > +		  * 1   SFP_DA_CORE
> > +		  * 2   SFP_SR/LR_CORE
> > +		  * 3   SFP_act_lmt_DA_CORE
> > +		  * 4   SFP_1g_cu_CORE
> > +		  * 5   SFP_1g_sx_CORE
> > +		  * 6   SFP_1g_lx_CORE
> > +		  */
> 
> So it looks like you have Linux driving the SFP, not firmware. In that case, please throw all this
code away.
> Implement a standard Linux I2C bus master driver, and make use of driver/net/phy/sfp*.[ch].
> 
>     Andrew
> 

I don't quite understand how to use driver/net/phy/sfp* files. In txgbe driver, I2C infos are read
from CAB registers, then SFP type identified.
Perhaps implement 'struct sfp_upstream_ops' ? And could you please guide me an example driver of
some docs?


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ