From patchwork Fri Jan 12 20:42:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Emiliano Ingrassia X-Patchwork-Id: 10161625 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 18D08602B3 for ; Fri, 12 Jan 2018 20:42:36 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 099F528952 for ; Fri, 12 Jan 2018 20:42:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F1C2F28A9A; Fri, 12 Jan 2018 20:42:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 59C0728952 for ; Fri, 12 Jan 2018 20:42:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965050AbeALUme (ORCPT ); Fri, 12 Jan 2018 15:42:34 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:45128 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964976AbeALUmc (ORCPT ); Fri, 12 Jan 2018 15:42:32 -0500 Received: by mail-wm0-f67.google.com with SMTP id i186so14430749wmi.4 for ; Fri, 12 Jan 2018 12:42:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=ppefyteSMFNCkxatajyAqw6XO37SCeDyybGkD3KQwEM=; b=MUYXQ/V4J6GCas6Qgfb7cNfe56L8LuZPpM6zRjp+C9k/FMJBrIByo8N+OwoRUbHrFB qCJjsEScolNeDZnJsSolfPZKRhvJ++lYd8LJWGJO5hda0e9rzg+VYlgbTQjeQ8IeK2I6 W5VCTLM3VU198l+AJlwCJRQwulgNxq4GxSg7BYc5az+SpYNUdriI3/U11LGAu48arFVI f8DoJiClLGbhMbFv0Gh+3WHdP/z3wlKHxyZRLOrAXE0noW9ygaU+3Qt7wcaukpXBv7Kd n2Xaz+LSyid4f+L/WMxr9FRtV1Z5w6mtn0eBV+6G8a1OArskjQo8O/P+yTuKEA4YPgzI 9RWA== X-Gm-Message-State: AKwxyteeFK5c+GuLEiPjq/o/AmGCp/HBUQTobuyHapRwgmm5nWgb1D+d C3sv6TckHBGUTe4oL5wfg8g= X-Google-Smtp-Source: ACJfBosC9QjrWrko1BjYV6eAWrx3OXyuvkeeWULaiKkiQehXsrezSu8jiwtTKjcASRXzAxzwnE1/XQ== X-Received: by 10.28.151.83 with SMTP id z80mr4454007wmd.99.1515789751762; Fri, 12 Jan 2018 12:42:31 -0800 (PST) Received: from ingrassia.epigenesys.com (host194-85-static.3-79-b.business.telecomitalia.it. [79.3.85.194]) by smtp.gmail.com with ESMTPSA id x127sm2992340wmb.36.2018.01.12.12.42.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jan 2018 12:42:30 -0800 (PST) Date: Fri, 12 Jan 2018 21:42:28 +0100 From: Emiliano Ingrassia To: Jean Delvare , Guenter Roeck Cc: linux-hwmon@vger.kernel.org Subject: [PATCH v3] hwmon: sht3x: wait predefined limits loading complete before access Message-ID: <20180112204228.GA1182@ingrassia.epigenesys.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-hwmon-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hwmon@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP An sht3x sensor include limits register which contains temperature and humidity limit values. After a reset, pre-defined values are loaded into that register. During the probe function, the driver reads the limits register. However, if the reads are made too early, and the bus is clocked at high frequencies (e.g. 100 kHz or more), the loading could be not completed and the sensor returns a NACK which causes the probe to fail. A delay of at least 500 us before the first read solves this issue. Signed-off-by: Emiliano Ingrassia --- drivers/hwmon/sht3x.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c index 6ea99cd6ae79..370b57dafab7 100644 --- a/drivers/hwmon/sht3x.c +++ b/drivers/hwmon/sht3x.c @@ -732,6 +732,13 @@ static int sht3x_probe(struct i2c_client *client, mutex_init(&data->i2c_lock); mutex_init(&data->data_lock); + /* + * An attempt to read limits register too early + * causes a NACK response from the chip. + * Waiting for an empirical delay of 500 us solves the issue. + */ + usleep_range(500, 600); + ret = limits_update(data); if (ret) return ret;