Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp117738yba; Wed, 3 Apr 2019 05:43:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqz4UOJjS8wAssY0TSJI8kBp25acDmZXYMP18HhmuCDnEXP98UZW2pKhndQ8bDowuVI9ajZy X-Received: by 2002:a17:902:820e:: with SMTP id x14mr13253886pln.207.1554295409555; Wed, 03 Apr 2019 05:43:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554295409; cv=none; d=google.com; s=arc-20160816; b=PgGA7gdactUcDqbUbeIC+y4XhHBCRcu+skxIrjI0akp98egn1et5mEQANRJvgJ+HN3 bZJLwuWPprp+4G47rjRgPHoTdgZRxcniT3ECZ+B8Y0JzddULwpQBif6iXfeNx5ev941M jUezRCj67BOh6OQXkyIwFUSy7Z4wh+wh4RKzQ7CNaDNurW9qD/UE+MW3z5s6bDPFCE9F QVYOiaiEcTxCi5+0NTCwova9CniHVtirlZtMAk+MwoDdKP8mF2slvnXMWqWD52FCMvao 92wS4wPSZTdNWGZ7jMxcdY1yQ8g58+N/FBdFmu1RthFPVlIi6k1hGC5nH6hTjs3wpGKe g7PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=gfUshQGPdKREmTk3i2Vb4c9sOe3Oo34Oq0lM4Z0DgDU=; b=zuKEOhLfVCeXEagA152omwfJ23Yn41BAFaSe4Xk5s1mJL+zu9s7wqFPVPgZskAj4Nd lKMo3m72+KZnMheuVbWqhq+S0YpC6Qw9pkWR/zSL/TVWm+8r6ag2RsltKACSDJZJUMYZ OZI8NtzmuPza6nzKYhGOUhbXT9wZKUGmiPpsQ/hUA+kUvtO1H2bQhlClZf8vYuM5mMLu HRNh2jkLTp/fkJOYtbuss++hQYMbiL+zJkaaXkCYfayUoLVVYb3CvxlzCO3MHeHlJYdE Ph8UUoueAap8oumvqKFi+SGU3NgFDcbnbR+Bk9BzzRrCvoL2gl37LjEPURwyBYq91916 L0LA== 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 k13si13584187pgo.246.2019.04.03.05.43.14; Wed, 03 Apr 2019 05:43:29 -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 S1726534AbfDCMkh (ORCPT + 99 others); Wed, 3 Apr 2019 08:40:37 -0400 Received: from sauhun.de ([88.99.104.3]:48284 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726206AbfDCMkg (ORCPT ); Wed, 3 Apr 2019 08:40:36 -0400 Received: from localhost (p54B3311F.dip0.t-ipconnect.de [84.179.49.31]) by pokefinder.org (Postfix) with ESMTPSA id F11803E604C; Wed, 3 Apr 2019 14:40:34 +0200 (CEST) From: Wolfram Sang To: linux-i2c@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Peter Rosin , Stefan Lengfeld , linux-omap@vger.kernel.org, linux-tegra@vger.kernel.org, Linus Walleij , Andy Shevchenko , Wolfram Sang Subject: [PATCH 01/12] i2c: remove use of in_atomic() Date: Wed, 3 Apr 2019 14:40:08 +0200 Message-Id: <20190403124019.8947-2-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20190403124019.8947-1-wsa+renesas@sang-engineering.com> References: <20190403124019.8947-1-wsa+renesas@sang-engineering.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit cea443a81c9c ("i2c: Support i2c_transfer in atomic contexts") added in_atomic() to the I2C core. However, the use of in_atomic() outside of core kernel code is discouraged and was already[1] when this code was added in early 2008. The above commit was a preparation for commit b7a3670131c7 ("i2c-pxa: Add polling transfer"). Its commit message says explicitly it was added "for cases where I2C transactions have to occur at times interrup[t]s are disabled". So, the intention was 'disabled interrupts'. This matches the use cases for atomic I2C transfers I have seen so far: very late communication (mostly to a PMIC) to powerdown or reboot the system. For those cases, interrupts are disabled then. It doesn't seem that in_atomic() adds value. After a discussion with Peter Zijlstra[2], we came up with a better set of conditionals to match the use case. The I2C core will soon gain an extra callback into bus drivers especially for atomic transfers to make them more generic. The code deciding which transfer to use (atomic/non-atomic) should mimic the behaviour which locking to use (trylock/lock). This is why we add a helper for it. [1] https://lwn.net/Articles/274695/ [2] http://patchwork.ozlabs.org/patch/1067437/ Signed-off-by: Wolfram Sang --- drivers/i2c/i2c-core-base.c | 2 +- drivers/i2c/i2c-core.h | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 38af18645133..f8502064cd6b 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1946,7 +1946,7 @@ int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num) * one (discarding status on the second message) or errno * (discarding status on the first one). */ - if (in_atomic() || irqs_disabled()) { + if (i2c_in_atomic_xfer_mode()) { ret = i2c_trylock_bus(adap, I2C_LOCK_SEGMENT); if (!ret) /* I2C activity is ongoing. */ diff --git a/drivers/i2c/i2c-core.h b/drivers/i2c/i2c-core.h index 37576f50fe20..9d8526415b26 100644 --- a/drivers/i2c/i2c-core.h +++ b/drivers/i2c/i2c-core.h @@ -29,6 +29,16 @@ extern int __i2c_first_dynamic_bus_num; int i2c_check_7bit_addr_validity_strict(unsigned short addr); +/* + * We only allow atomic transfers for very late communication, e.g. to send + * the powerdown command to a PMIC. Atomic transfers are a corner case and not + * for generic use! + */ +static inline bool i2c_in_atomic_xfer_mode(void) +{ + return system_state > SYSTEM_RUNNING && irqs_disabled(); +} + #ifdef CONFIG_ACPI const struct acpi_device_id * i2c_acpi_match_device(const struct acpi_device_id *matches, -- 2.11.0