From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chas Williams <3chas3@gmail.com> Subject: Re: [PATCH v3 1/2] net/ixgbe: fix x550 code to handle unidentified PHY Date: Mon, 5 Nov 2018 13:18:49 -0500 Message-ID: <494f9ba9-cadc-aa36-2b17-42890dbe5c74@gmail.com> References: <20180815170932.23536-1-bluca@debian.org> <20181102151848.18024-1-bluca@debian.org> <039ED4275CED7440929022BC67E70611532DF9A9@SHSMSX103.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Lu, Wenzhuo" , "Ananyev, Konstantin" , "stable@dpdk.org" To: "Zhang, Qi Z" , Luca Boccassi , "dev@dpdk.org" Return-path: In-Reply-To: <039ED4275CED7440929022BC67E70611532DF9A9@SHSMSX103.ccr.corp.intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 11/05/2018 12:41 PM, Zhang, Qi Z wrote: > > >> -----Original Message----- >> From: Luca Boccassi [mailto:bluca@debian.org] >> Sent: Friday, November 2, 2018 8:19 AM >> To: dev@dpdk.org >> Cc: Lu, Wenzhuo ; Ananyev, Konstantin >> ; Zhang, Qi Z ; >> 3chas3@gmail.com; Luca Boccassi ; stable@dpdk.org >> Subject: [PATCH v3 1/2] net/ixgbe: fix x550 code to handle unidentified PHY >> >> ixgbe_identify_sfp_module_X550em() was missing the code to handle >> unidentified PHY that has been there in 82599 so it was not able to complete >> initialization of ixgbe sequence if no sfp plugged in. >> Port it over to return an appropriate type and complete init sequence >> properly. >> >> Fixes: d2e72774e58c ("ixgbe/base: support X550") >> Cc: stable@dpdk.org >> >> Signed-off-by: Luca Boccassi >> --- >> v2: refresh to remove merge conflict with master >> v3: coalesce fix into ixgbe_identify_sfp_module_X550em to avoid >> code duplication, improve comment >> >> drivers/net/ixgbe/base/ixgbe_x550.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c >> b/drivers/net/ixgbe/base/ixgbe_x550.c >> index f7b98af52..a88d5c86a 100644 >> --- a/drivers/net/ixgbe/base/ixgbe_x550.c >> +++ b/drivers/net/ixgbe/base/ixgbe_x550.c >> @@ -1561,6 +1561,12 @@ s32 ixgbe_identify_sfp_module_X550em(struct >> ixgbe_hw *hw) >> >> status = ixgbe_identify_module_generic(hw); >> >> + /* Set PHY type none if no PHY detected to allow init without SFP */ >> + if (hw->phy.type == ixgbe_phy_unknown) { >> + hw->phy.type = ixgbe_phy_none; > > Set PHY type to none for a device that does have PHY looks weird. > does ixgeb_phy_generic works here? Yes, it does seem strange but that's what ixgbe_identify_sfp_module_generic seems to do: err_read_i2c_eeprom: hw->phy.sfp_type = ixgbe_sfp_type_not_present; if (hw->phy.type != ixgbe_phy_nl) { hw->phy.id = 0; hw->phy.type = ixgbe_phy_unknown; } The QSFP version a little more forceful: err_read_i2c_eeprom: hw->phy.sfp_type = ixgbe_sfp_type_not_present; hw->phy.id = 0; hw->phy.type = ixgbe_phy_unknown; If we go forward without setting the phy_type to none, we will eventually run into issues calling other phy routines. So should a lack of SFP, reset the PHY type? It's hazy because the difference between PHY and SFP isn't that clear to me here. > Where is failure you met with ixgbe_phy_unknown? > >> + return IXGBE_SUCCESS; >> + } >> + >> if (status != IXGBE_SUCCESS) >> return status; >> >> -- >> 2.19.1 >