From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACD88C433DB for ; Thu, 7 Jan 2021 09:09:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66B5C22CF8 for ; Thu, 7 Jan 2021 09:09:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727188AbhAGJJb (ORCPT ); Thu, 7 Jan 2021 04:09:31 -0500 Received: from mail.kernel.org ([198.145.29.99]:42728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726366AbhAGJJa (ORCPT ); Thu, 7 Jan 2021 04:09:30 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 94D3C22CF8; Thu, 7 Jan 2021 09:08:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610010529; bh=hT97XartlDHHyLDpDxHrJy2mQbx9clbET9d1rFFIMnU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fuuzM7bXlJTmuYJcYr1oP1ARilEgGsLARTCFhVWMMcojccFClLi8TuPqErlVqDWGE HYj68efsVVsbwCs5baQYUSA2mylVbUkVcxUCAutz08UpSuaPQvm/GIj5cTte7EriAx FMA7OP74b1NVFQUAiVMPR+00jotp7Fg5SJv+sj0MLH7SCtr5oIBdcRJRJDIx1DPhiX D3EaHLRaRNwkuNTtLR19pRUFp33qONSRGd8sBhkqfM1+ESbIco00JjZ5SdYYGHTAQU b3aqT5y0OoHZOC+emOBHWxlc55w4ciFRrxpxkWwAMhx50zQ2SCN2m3ZXWjXHQgD+Ni t1cCNcYpxf3Mw== Received: by pali.im (Postfix) id 2F60E77B; Thu, 7 Jan 2021 10:08:47 +0100 (CET) Date: Thu, 7 Jan 2021 10:08:46 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Andrew Lunn Cc: Russell King - ARM Linux admin , "David S. Miller" , Jakub Kicinski , Thomas Schreiber , Heiner Kallweit , Marek =?utf-8?B?QmVow7pu?= , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips Message-ID: <20210107090846.rxi7yo7adxumjmi3@pali> References: <20201230154755.14746-1-pali@kernel.org> <20210106153749.6748-1-pali@kernel.org> <20210106153749.6748-2-pali@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thursday 07 January 2021 03:02:36 Andrew Lunn wrote: > > + /* hwmon interface needs to access 16bit registers in atomic way to > > + * guarantee coherency of the diagnostic monitoring data. If it is not > > + * possible to guarantee coherency because EEPROM is broken in such way > > + * that does not support atomic 16bit read operation then we have to > > + * skip registration of hwmon device. > > + */ > > + if (sfp->i2c_block_size < 2) { > > + dev_info(sfp->dev, "skipping hwmon device registration " > > + "due to broken EEPROM\n"); > > + dev_info(sfp->dev, "diagnostic EEPROM area cannot be read " > > + "atomically to guarantee data coherency\n"); > > + return; > > + } > > This solves hwmon. But we still return the broken data to ethtool -m. > I wonder if we should prevent that? Looks like that it is not too simple for now. And because we already export these data for these broken chips in current mainline kernel, I would propose to postpone fix for ethtool and let it for future patches. This patch series does not change (nor make it worse) behavior.