From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A050D2572 for ; Tue, 18 Apr 2023 12:46:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28343C433EF; Tue, 18 Apr 2023 12:46:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1681821969; bh=JUtvAktBbQEAeRT3WazZd4Ldw4ww38/tAHstPkrbmVo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=In1d6+sEoBBqtvvUzHfD+i2uplEbpnSECsI1WJg0Tp+S/7ZOZzG9PT67mcXZojoCN 1fL2+S6+EWRL20P587vFIwiORklF5s7118EivPCBEud9EkbCT1qgOa8JHBwl6GwgG3 9D9ST1F1b7T6nuQ3MgygRunSsUS51YysgUUfQbuY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ivan Bornyakov , Andrew Lunn , "David S. Miller" Subject: [PATCH 6.1 106/134] net: sfp: initialize sfp->i2c_block_size at sfp allocation Date: Tue, 18 Apr 2023 14:22:42 +0200 Message-Id: <20230418120316.897496059@linuxfoundation.org> X-Mailer: git-send-email 2.40.0 In-Reply-To: <20230418120313.001025904@linuxfoundation.org> References: <20230418120313.001025904@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ivan Bornyakov commit 813c2dd78618f108fdcf9cd726ea90f081ee2881 upstream. sfp->i2c_block_size is initialized at SFP module insertion in sfp_sm_mod_probe(). Because of that, if SFP module was never inserted since boot, sfp_read() call will lead to zero-length I2C read attempt, and not all I2C controllers are happy with zero-length reads. One way to issue sfp_read() on empty SFP cage is to execute ethtool -m. If SFP module was never plugged since boot, there will be a 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 If SFP module was plugged then removed at least once, sfp->i2c_block_size will be initialized and ethtool -m will fail with different exit code and without I2C error # ethtool -m xge0 Cannot get Module EEPROM data: Remote I/O error Fix this by initializing sfp->i2_block_size at struct sfp allocation stage so no wild sfp_read() could issue zero-length I2C read. Signed-off-by: Ivan Bornyakov Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/phy/sfp.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) --- a/drivers/net/phy/sfp.c +++ b/drivers/net/phy/sfp.c @@ -212,6 +212,12 @@ static const enum gpiod_flags gpio_flags #define SFP_PHY_ADDR 22 #define SFP_PHY_ADDR_ROLLBALL 17 +/* SFP_EEPROM_BLOCK_SIZE is the size of data chunk to read the EEPROM + * at a time. Some SFP modules and also some Linux I2C drivers do not like + * reads longer than 16 bytes. + */ +#define SFP_EEPROM_BLOCK_SIZE 16 + struct sff_data { unsigned int gpios; bool (*module_supported)(const struct sfp_eeprom_id *id); @@ -1928,11 +1934,7 @@ static int sfp_sm_mod_probe(struct sfp * u8 check; int ret; - /* Some SFP modules and also some Linux I2C drivers do not like reads - * longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at - * a time. - */ - sfp->i2c_block_size = 16; + sfp->i2c_block_size = SFP_EEPROM_BLOCK_SIZE; ret = sfp_read(sfp, false, 0, &id.base, sizeof(id.base)); if (ret < 0) { @@ -2615,6 +2617,7 @@ static struct sfp *sfp_alloc(struct devi return ERR_PTR(-ENOMEM); sfp->dev = dev; + sfp->i2c_block_size = SFP_EEPROM_BLOCK_SIZE; mutex_init(&sfp->sm_mutex); mutex_init(&sfp->st_mutex);