Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3738045ybg; Mon, 28 Oct 2019 18:26:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqyyAD7RwFrBRHViXan7xb+zdWUaDXfhDQJfmaSSqe4AuARoIXHnA3sLsv8i7F6qfhYaSXJP X-Received: by 2002:aa7:d891:: with SMTP id u17mr22417793edq.282.1572312390795; Mon, 28 Oct 2019 18:26:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572312390; cv=none; d=google.com; s=arc-20160816; b=ipWJ3gk/CGs8SnM6MnIWlHUa+SIpOAOxhdzt/HCUyDKQ4HOpxCrNwABokD01f3HXSs aFOm/vIwrrOwpBziElx6QmmTB9SMbJWWLznniw4Q31ggFeG9+asfR3HcmgWQBdABmq75 aMbtD1X0WXu3xr6g6F4B2+T8IwEO9SYsnVXHZSlqgMY1wvlwMuCShE6YhMbU8lTb0hgC czC5qXtEOhOemyStnqCxAqYKjUFLWWR7Zd71hS1MGhwjQSp3Szfgun7jOz9wTawCLU1E qdYfaHHzhel5UjYOH783LCYe7pmJRSX1f6hSlyLPZFR8ZXE0yuSMpZlE2BaqyzIxEwS3 WXtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=4F0ht6G2TT+MREoDd6rA7D4A0FfWsuaLZ64t+L13ZAM=; b=WC2LxanN8ZKL+gLuls/ysYWrayDf2FG3YuBdgFO1XeaCFk2pRxzjO9BMKmKVOQuF94 08rt1Sgl8sVDg1tx+9I+SBsdxv0XpAnuE9alzHcFgNCGIqzu/oNHUGTFkE1dyy23R5c1 rusTYFF1luYFxZLfkUPVaE0WiTljKyWk+/b/rZDDkbfH/VHxNT7JZ0z+fl8hOatsGM+G ZOnlgbxT4dWHSJ5NsYEL9E8W8NflUlTKpPa6MkylhfY4Dj/yUKmfUveWbHBBiqLGa+4C s3HhYfRarvhpAqVUd6s9E2dnk/LWedpyML7edPzPR1auvXlytnqQcFhccBZzmspX3Xn/ 42uw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si7271516ejs.199.2019.10.28.18.26.07; Mon, 28 Oct 2019 18:26:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388061AbfJ1JqX (ORCPT + 99 others); Mon, 28 Oct 2019 05:46:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:40908 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730038AbfJ1JqX (ORCPT ); Mon, 28 Oct 2019 05:46:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5B172B239; Mon, 28 Oct 2019 09:46:21 +0000 (UTC) Date: Mon, 28 Oct 2019 10:46:18 +0100 From: Jean Delvare To: Rain Wang Cc: Guenter Roeck , linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org Subject: Re: [PATCH] lm75: add lm75b detection Message-ID: <20191028104618.5f21af38@endymion> In-Reply-To: <7a2ddf42-8bbe-59e0-dae8-85b184ea0da0@roeck-us.net> References: <20191026081049.GA16839@rainw-fedora28-jabil.corp.JABIL.ORG> <7a2ddf42-8bbe-59e0-dae8-85b184ea0da0@roeck-us.net> Organization: SUSE Linux X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 27 Oct 2019 16:03:39 -0700, Guenter Roeck wrote: > On 10/26/19 1:10 AM, Rain Wang wrote: > > The National Semiconductor LM75B is very similar as the > > LM75A, but it has no ID byte register 7, and unused registers > > return 0xff rather than the last read value like LM75A. Please send hwmon-related patches to the linux-hwmon list. > > Signed-off-by: Rain Wang > > I am quite hesitant to touch the detect function for this chip. > Each addition increases the risk for false positives. What is the > use case ? I'm positively certain I don't want this. Ideally there should be no detection at all for device without ID registers. The only reason there are some occurrences of that is because there were no way to explicitly instantiate I2C devices back then, and we have left the detection in place to avoid perceived regressions. But today there are plenty of ways to explicitly instantiate your I2C devices so there are no excuses for more crappy detect functions. Ideally we would even get rid of existing ones at some point in the future. This patch is bad anyway as it only changes the device name without implementing proper support for the LM75B. -- Jean Delvare SUSE L3 Support