From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Fainelli Subject: Re: [PATCH net-next 1/4] net: phy: sfp: Do not reject soldered down modules Date: Thu, 9 Nov 2017 20:39:09 -0800 Message-ID: <1b490bbc-8200-31c8-d9ef-ff8be0ad27fd@gmail.com> References: <20171108034911.16382-1-f.fainelli@gmail.com> <20171108034911.16382-2-f.fainelli@gmail.com> <20171108111549.GQ9463@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch To: Russell King - ARM Linux Return-path: Received: from mail-qk0-f196.google.com ([209.85.220.196]:50856 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755926AbdKJEjN (ORCPT ); Thu, 9 Nov 2017 23:39:13 -0500 Received: by mail-qk0-f196.google.com with SMTP id p7so10509767qkd.7 for ; Thu, 09 Nov 2017 20:39:12 -0800 (PST) In-Reply-To: <20171108111549.GQ9463@n2100.armlinux.org.uk> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 11/08/2017 03:15 AM, Russell King - ARM Linux wrote: > On Tue, Nov 07, 2017 at 07:49:08PM -0800, Florian Fainelli wrote: >> The SFP module identification code in sfp_sm_mod_probe() will reject SFF >> modules soldered down because they have an identified of 0x2, while the code >> currently checks for 0x3 only (SFP_PHYS_ID_SFP), update that. >> >> Signed-off-by: Florian Fainelli >> --- >> drivers/net/phy/sfp.c | 5 +++-- >> include/linux/sfp.h | 1 + >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c >> index e381811e5f11..942288aa9cdb 100644 >> --- a/drivers/net/phy/sfp.c >> +++ b/drivers/net/phy/sfp.c >> @@ -463,8 +463,9 @@ static int sfp_sm_mod_probe(struct sfp *sfp) >> vendor, part, rev, sn, date); >> >> /* We only support SFP modules, not the legacy GBIC modules. */ >> - if (sfp->id.base.phys_id != SFP_PHYS_ID_SFP || >> - sfp->id.base.phys_ext_id != SFP_PHYS_EXT_ID_SFP) { >> + if ((sfp->id.base.phys_id != SFP_PHYS_ID_SFP && >> + sfp->id.base.phys_id != SFP_PHYS_ID_SFF) || >> + sfp->id.base.phys_ext_id != SFP_PHYS_EXT_ID_SFP) { > > I'd prefer that we do something like the patch I sent a couple of nights > ago, having a separate compatible for the SFF modules (since they have > no insert signal as SFF is soldered in place) and use that to decide > which phys_id we accept here. Fair enough. -- Florian