Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1253277rwl; Wed, 5 Apr 2023 14:13:03 -0700 (PDT) X-Google-Smtp-Source: AKy350Z0qcUpZth4aFmxr1zdDo77l98QeXOr+qApBwx62iVPfuYdyzTXeSFlsijk5kZ0g7SBKbdf X-Received: by 2002:a17:906:5fd1:b0:91f:b13f:a028 with SMTP id k17-20020a1709065fd100b0091fb13fa028mr4067467ejv.34.1680729183580; Wed, 05 Apr 2023 14:13:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680729183; cv=none; d=google.com; s=arc-20160816; b=UjgTp3GYG9LWpTIMUF7vEZwg3RQ/+9tgajoQHnbfKr6v5OrBgSE5/+3PNq7+eQZ9oL uHkcXkeChvDo0A2SvOcVCrFJNtOpUKkPgw+XoUSQwuNFs0cCYbaegQtcvXQZAxyprEEs iX98PTAmj+hC/nZu/lnH35XyFwlpnREjNdLiukx7AKLuYW4et2ANwMebAxR1YpfrkW+K hr1FqZqenbupES6wtgDz/IKVkV/9S+3VNFdJdUNUxSfYr8Ub+1bwJTrn4wV0QpjAwAZ2 ATwy77BK8GPMbHdSlbkgLAiKYuZp4/1Pyu9sksWVej7TRHn0XdkPcNQaVO/LAFQJavKI glyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FWdfeNCEqoPN2w3fXlRUMfRID8BRxTZHwrIcMhqUrd8=; b=cve4JRkXQQxqw4cnn8s4yRn8gfQ5d46+Wogn2Vet4D/SiAvi4GUQz2NZeeKa3FAn/F fX+iQPUumb+v2RjexyauTtUyFe0Gs4GT0W2bu1/2yNQkES62LS2vjJyGht6rPu2LCzTn Ce8A//u0JCFalKI0fn6b0/7X8ZsL+lY/6Dl2oiDKhx2ElGO5I7Zljlt9N8He5GAEPWmm Ae25jWIAmr9W6R3klbCH2xK9D3r0BqzyQiRtCApc3T1AabCJsss9FVbWFDKSQv/umN66 I7fuUKSbdJ9fIyNB9iSH0/vLWXopNBQpmMzbuZILq55YojP8+Km4O7KxlB3Ym1scsHvt aqtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@metrotek.ru header.s=mail header.b=C4V+NPIo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l9-20020a1709066b8900b009217e23a19esi414053ejr.599.2023.04.05.14.12.35; Wed, 05 Apr 2023 14:13:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@metrotek.ru header.s=mail header.b=C4V+NPIo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233973AbjDEVMI (ORCPT + 99 others); Wed, 5 Apr 2023 17:12:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229907AbjDEVMH (ORCPT ); Wed, 5 Apr 2023 17:12:07 -0400 Received: from mail.pr-group.ru (mail.pr-group.ru [178.18.215.3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2534CBE; Wed, 5 Apr 2023 14:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=metrotek.ru; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=nvlDqqC1HZuZQCP4v7nUD2qz1uhbB8cOkjERLKw3KrA=; b=C4V+NPIo1+xxWmyO0NQH7xUErAJZJX3oSffFr23lsnd01cYkB0mRAWDizGRCgSk2ZG1OIYDlKvy+l cFFyYcF7sEgP7iRmQhC5A8hv40I7XSRTN8vHKjGOgoCD4VhUkHCxQIHBT5u6e9KAONrQJqYBns3J7z PZnoECnVU0CZwoFLTQvzDKyF2nH1z+MDxZRpUf3TSl2uTgpbibHQQvh++s5wniVz/52vIZ6aa3KT8r EXlWqJBO3wbVwooBoAWCAOqWt0kTBzYT4Zhs7K/a8vMRReOFNBHvmsnRDH2QdUTdzTwfL/kFmJ5NM4 2qBSXjv/UO4EvsDsLJxdm5j/ApflHfg== X-Kerio-Anti-Spam: Build: [Engines: 2.17.2.1477, Stamp: 3], Multi: [Enabled, t: (0.000043,0.009637)], BW: [Enabled, t: (0.000025,0.000001)], RTDA: [Enabled, t: (0.072898), Hit: No, Details: v2.49.0; Id: 15.zzc5h.1gt9ie61g.171og; mclb], total: 0(700) X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Level: X-Footer: bWV0cm90ZWsucnU= Received: from x260 ([78.37.166.219]) (authenticated user i.bornyakov@metrotek.ru) by mail.pr-group.ru with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 5 Apr 2023 23:41:21 +0300 Date: Wed, 5 Apr 2023 23:41:16 +0300 From: Ivan Bornyakov To: Andrew Lunn Cc: netdev@vger.kernel.org, linux@armlinux.org.uk, hkallweit1@gmail.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, linux-kernel@vger.kernel.org, system@metrotek.ru, stable@vger.kernel.org Subject: Re: [PATCH net] net: sfp: initialize sfp->i2c_block_size at sfp allocation Message-ID: <20230405204116.mo5j6klyjnuvenag@x260> References: <20230405153900.747-1-i.bornyakov@metrotek.ru> <19d7ef3c-de9d-4a44-92e9-16ac14b663d9@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19d7ef3c-de9d-4a44-92e9-16ac14b663d9@lunn.ch> X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 05, 2023 at 09:35:31PM +0200, Andrew Lunn wrote: > On Wed, Apr 05, 2023 at 06:39:00PM +0300, Ivan Bornyakov wrote: > > sfp->i2c_block_size is initialized at SFP module insertion in > > sfp_sm_mod_probe(). Because of that, if SFP module was not inserted > > since boot, ethtool -m leads to zero-length I2C read attempt. > > > > # ethtool -m xge0 > > i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read) > > Cannot get Module EEPROM data: Operation not supported > > Do i understand you correct in that this is when the SFP cage has > always been empty? The I2C transaction is going to fail whatever the > length is. > Yes, SFP cage is empty, I2C transaction will fail anyways, but not all I2C controllers are happy about zero-length reads. > > If SFP module was plugged then removed at least once, > > sfp->i2c_block_size will be initialized and ethtool -m will fail with > > different error > > > > # ethtool -m xge0 > > Cannot get Module EEPROM data: Remote I/O error > > So again, the SFP cage is empty? > > I wonder if a better fix is to use > > sfp->state & SFP_F_PRESENT > > in sfp_module_eeprom() and sfp_module_eeprom_by_page() and don't even > do the I2C read if there is no module in the cage? > This is also worthy addition to sfp.c, but IMHO sfp->i2c_block_size initialization still need to be fixed since $ grep -c "sfp_read(" drivers/net/phy/sfp.c 31 and I can't vouch all of them are possible only after SFP module insertion. Also for future proof reason.