From patchwork Wed Mar 27 21:12:56 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 10873945 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3520317E0 for ; Wed, 27 Mar 2019 21:13:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1B51228C12 for ; Wed, 27 Mar 2019 21:13:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0E7E328C1D; Wed, 27 Mar 2019 21:13:39 +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=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B38F028C12 for ; Wed, 27 Mar 2019 21:13:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=e0Nzb4lsS9fiAfLDgYnh2bzc7ZaR3iLKckdgfeM3HhM=; b=CtT1BTt9avE/11 aq4S1OTV7xLsmYi0MUB140dLSHIzjipIL9FjjVQfwpDPGFvGlZTBF8MgAMquGahJvDd8iu++MQwTQ V3FOUW+wIdpk2IKFreLWd/G5wIQfwb/g+6Pqx74Fkz9eMAVOgbKFuInq5yTejHi980ReQLxrOPPcj SIRkCaf8zX6Fccs6PyuYbI//Q5OkCNYUsP69prjVvECe7m3f99KxKq850U/P00VhNYDVgKCtulXJ+ 85NWEInGdN367VQx90SXErfhHojAur9nBwudfGCCqJu6MN9OmOlRGBke277nvsTmS4gRcruBlpSk9 2GkNFzLkbYyVriSU6NvQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9FrX-0001pT-98; Wed, 27 Mar 2019 21:13:31 +0000 Received: from sauhun.de ([88.99.104.3] helo=pokefinder.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h9FrT-0001oM-Ki for linux-arm-kernel@lists.infradead.org; Wed, 27 Mar 2019 21:13:29 +0000 Received: from localhost (p5486CE6B.dip0.t-ipconnect.de [84.134.206.107]) by pokefinder.org (Postfix) with ESMTPSA id E72342E35A2; Wed, 27 Mar 2019 22:13:18 +0100 (CET) From: Wolfram Sang To: linux-i2c@vger.kernel.org Subject: [RFC PATCH] i2c: remove use of in_atomic() Date: Wed, 27 Mar 2019 22:12:56 +0100 Message-Id: <20190327211256.17232-1-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190327_141327_828336_A07D23E8 X-CRM114-Status: GOOD ( 14.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Frederic Weisbecker , linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Wolfram Sang , Ingo Molnar , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP 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 b7a3670131c7 ("i2c-pxa: Add polling transfer"). Its commit message says explicitly it was added "for cases where I2C transactions have to occur at times interrups 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. Note that only ~10 out of ~120 bus master drivers support atomic transfers, mostly by polling always when no irq is supplied. A generic I2C client driver cannot assume support for atomic transfers. This is currently a platform-dependent corner 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). Because I don't want to add more in_atomic() to the I2C core, this patch simply removes it. [1] https://lwn.net/Articles/274695/ Signed-off-by: Wolfram Sang --- So, I had to dive into this in_atomic() topic and this is what I concluded. I don't see any reasonable constellation where this could cause a regression, but I am all open for missing something and being pointed to it. This is why the patch is RFC. I'd really welcome comments. Thanks! drivers/i2c/i2c-core-base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 38af18645133..943bebeec3ed 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 (irqs_disabled()) { ret = i2c_trylock_bus(adap, I2C_LOCK_SEGMENT); if (!ret) /* I2C activity is ongoing. */