From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id B1569293B; Fri, 2 Nov 2018 18:08:03 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id d17-v6so2675748wre.11; Fri, 02 Nov 2018 10:08:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=VfC96f9kqnAOAR7HVSnaYEc7hNFMVPeCF7elwtbnjKM=; b=SF7irRqpop/3LyU7iTMHImri06cSXOBgY8pZNergSeXeYswaaDrz9NE5kTNFtwLbV5 diC4qepoQamyywgkKs30F/L6uXIwE8Hr0h3zwj9DZMzxBJuMwmTqrFHGpkIXe4Wd2HnJ GkTt5kDFlno8mS9+Uh49K+JTtqeW17QNkgQKPlJ7lNgzWjH6Qm1zZ8URwtKfqNzaz6ni LGMl55h0woL4f8XfL1It3OVMlf57V391OLPgJE58Nv1iqLbIPz/mBbuOt5dNXSjXovpH t3/ERJur0RMt23ylfDMDxjihU9uq7Am/FTk7LdQXBLC1WduHx1iH58xkRIuS0Fw+PkfE uK0Q== X-Gm-Message-State: AGRZ1gLRv992liLltxhiZa+QIQgVy/U7m4vK9R3RnxaaeruVyh/dKelZ YCIB+0VkztOFPHLsUACAO0I= X-Google-Smtp-Source: AJdET5eHzYPOtf3r0VzQerhJrgfW2RJ5NznaYJgvOeYIs4KoQIg9kK456fOm1lAFd6oF6i1j19RraQ== X-Received: by 2002:adf:8141:: with SMTP id 59-v6mr10237001wrm.128.1541178483137; Fri, 02 Nov 2018 10:08:03 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id 140-v6sm25289604wmx.34.2018.11.02.10.08.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 02 Nov 2018 10:08:02 -0700 (PDT) Message-ID: <1541178480.4849.26.camel@debian.org> From: Luca Boccassi To: "Zhang, Qi Z" , "dev@dpdk.org" Cc: "Lu, Wenzhuo" , "Ananyev, Konstantin" , "stable@dpdk.org" , 3chas3@gmail.com Date: Fri, 02 Nov 2018 17:08:00 +0000 In-Reply-To: <039ED4275CED7440929022BC67E70611532DEC2C@SHSMSX103.ccr.corp.intel.com> References: <20180815170932.23536-1-bluca@debian.org> <20181101140413.18665-1-bluca@debian.org> <039ED4275CED7440929022BC67E70611532DEB42@SHSMSX103.ccr.corp.intel.com> <1541172065.4849.22.camel@debian.org> <039ED4275CED7440929022BC67E70611532DEC2C@SHSMSX103.ccr.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 1/2] net/ixgbe: fix x550 code to handle unidentified PHY X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 17:08:03 -0000 On Fri, 2018-11-02 at 16:49 +0000, Zhang, Qi Z wrote: > > -----Original Message----- > > From: Luca Boccassi [mailto:bluca@debian.org] > > Sent: Friday, November 2, 2018 10:21 AM > > To: Zhang, Qi Z ; dev@dpdk.org > > Cc: Lu, Wenzhuo ; Ananyev, Konstantin > > ; stable@dpdk.org > > Subject: Re: [PATCH 1/2] net/ixgbe: fix x550 code to handle > > unidentified PHY > >=20 > > On Fri, 2018-11-02 at 14:11 +0000, Zhang, Qi Z wrote: > > > > -----Original Message----- > > > > From: Luca Boccassi [mailto:bluca@debian.org] > > > > Sent: Thursday, November 1, 2018 9:04 AM > > > > To: dev@dpdk.org > > > > Cc: Lu, Wenzhuo ; Ananyev, Konstantin > > > > ; Zhang, Qi Z > > > om>; > > > > Luca Boccassi ; stable@dpdk.org > > > > Subject: [PATCH 1/2] net/ixgbe: fix x550 code to handle > > > > unidentified > > > > PHY > > > >=20 > > > > ixgbe_identify_phy_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. > > > >=20 > > > > Fixes: d2e72774e58c ("ixgbe/base: support X550") > > > > Cc: stable@dpdk.org > > > >=20 > > > > Signed-off-by: Luca Boccassi > > > > --- > > > > v2: refresh to remove merge conflict with master > > > >=20 > > > > =C2=A0drivers/net/ixgbe/base/ixgbe_x550.c | 19 ++++++++++++++++--- > > > > =C2=A01 file changed, 16 insertions(+), 3 deletions(-) > > > >=20 > > > > diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c > > > > b/drivers/net/ixgbe/base/ixgbe_x550.c > > > > index f7b98af52..83b394861 100644 > > > > --- a/drivers/net/ixgbe/base/ixgbe_x550.c > > > > +++ b/drivers/net/ixgbe/base/ixgbe_x550.c > > > > @@ -315,13 +315,21 @@ STATIC void ixgbe_setup_mux_ctl(struct > > > > ixgbe_hw > > > > *hw) > > > > =C2=A0 */ > > > > =C2=A0STATIC s32 ixgbe_identify_phy_x550em(struct ixgbe_hw *hw)=C2= =A0=C2=A0{ > > > > + s32 status; > > > > + > > > > =C2=A0 hw->mac.ops.set_lan_id(hw); > > > >=20 > > > > =C2=A0 ixgbe_read_mng_if_sel_x550em(hw); > > > >=20 > > > > =C2=A0 switch (hw->device_id) { > > > > =C2=A0 case IXGBE_DEV_ID_X550EM_A_SFP: > > > > - return ixgbe_identify_sfp_module_X550em(hw); > > > > + status =3D ixgbe_identify_sfp_module_X550em(hw); > > > > + /* Set PHY type none if no PHY detected */ > > > > + if (hw->phy.type =3D=3D ixgbe_phy_unknown) { > > > > + hw->phy.type =3D ixgbe_phy_none; > > > > + return IXGBE_SUCCESS; > > > > + } > > >=20 > > > Why this can't be handled at caller, why we replace phy_unknown > > > by > > > phy_none only for x550? > >=20 > > Hi, thanks for the review. > >=20 > > I've moved the code into the caller in v3. >=20 > Sorry, this is not what I suggested.=C2=A0 > I'm not sure for X550EM_A_SFP, it is the case that the device does > not have PHY so we should correct it (by replace it with no_phy)=C2=A0 > or it is the case that we can't identify PHY so we just replace it by > no_phy to bypass the check for workaround? > If the second case, is it possible not to do replacement and handle > it at upper layer (caller or caller's caller ... ) and keep the > information more accurate? It is the second case - I've amended the comment in v3, the issue is that the driver will fail to initialise if there is no SFP present at boot (not very hotplug-friendly!). The issue with calling it one layer above is that this function is saved in a table, and there are at least 3-4 places where it is called from. So it would have to be repeated many times, and also I'm not 100% sure of all the places where to do this, as the function table is updated several times across the base driver. So, when you say caller or caller's caller, do you have identified precisely where? I'm happy to change it if you can point me exactly to the right places. Thanks! > >=20 > > It's done for x550 simply because that's the hardware that we have > > and that > > this was tested with, I didn't want to take extra risks. It's also > > the hardware > > that our customer reported the issue with. >=20 >=20 > >=20 > > -- > > Kind regards, > > Luca Boccassi --=20 Kind regards, Luca Boccassi