Received: by 10.223.185.116 with SMTP id b49csp2745780wrg; Sun, 25 Feb 2018 05:22:18 -0800 (PST) X-Google-Smtp-Source: AH8x226EwTKFKtaOWKGc5oEyM8keLF+yBdYWGckWmOy6pVkwAAbt/IsjaRsygWlj+aPQ0H08zNr4 X-Received: by 2002:a17:902:b613:: with SMTP id b19-v6mr7455897pls.173.1519564938109; Sun, 25 Feb 2018 05:22:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519564938; cv=none; d=google.com; s=arc-20160816; b=CANDuV9LODE4lcL3WI/F5OURQGvqNAtEu6blrHMc60+EEXDPH1T9MbfkR2lK7BL3Ge 7q8EkiTwrpf0AhbR5rCWaYjr8GKr5TN2wkcmkKqpT25iBVH2O/eWUDgI5sv6kxbqE7KJ bUlf0YIFbCaszPQdBpAVsIHnzTGhwMYfPGRZeUixS0ZEgT3v0t3mdT2l/lZnI/RLpprl bLweGMvROAT8fmP/wUL3u9KeuXBJ8R3ACpvFOSzLj0rfoBnpSCejF+5otXVEmkBf2/If ZM1NrpBRNVf+DpIpWaFcYck6rcODeHfY7rc3p20kCh4uSpNk+A2Pa1fD1dpi9fCzV1cg 6hlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=arr8XsFtQ5CKqHKLqlEbRiRTLol9DEaR1fj207qUKXY=; b=Kuu26tXLFiKX1iMl0n/24rxk8/gmr3ZMTL9TMENmYgP+JP5ImIL3qpv7pZJdQjR/NT iI67ZnwaOLgql6op4VONBJEooi4NGttXPtP8oE7RtPJ26rvV1NWHzVZdkkk7K1t+pnvI 7K+IqtcFPLaP9rnrX9L1sJy1RptYpsYdc82LlfZRb4ZevDH4eNs7RdPwt7avz4fglcNv m24xdZR3FeoGEyxtKg2RoG3Sx9HJCjKFMb7tSw3iOh/i7LC1ZQz8cnw/CweVfc9pUT6B IqTf+id5HmSd3zGUinJi0bQnOVrMBw1lYSbT/okB+mnTnc5oBlJHFwhGBVDsUMDBaz+7 I1uQ== 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 b96-v6si5163292pli.145.2018.02.25.05.21.52; Sun, 25 Feb 2018 05:22:18 -0800 (PST) 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 S1751771AbeBYNUx (ORCPT + 99 others); Sun, 25 Feb 2018 08:20:53 -0500 Received: from 178.115.242.59.static.drei.at ([178.115.242.59]:38954 "EHLO mail.osadl.at" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751699AbeBYNUu (ORCPT ); Sun, 25 Feb 2018 08:20:50 -0500 Received: by mail.osadl.at (Postfix, from userid 1001) id 747C15C053E; Sun, 25 Feb 2018 13:20:14 +0000 (UTC) Date: Sun, 25 Feb 2018 13:20:14 +0000 From: Nicholas Mc Guire To: Tobias Jordan Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Wolfram Sang Subject: Re: [SIL2review] [PATCH] i2c: img-scb: fix PM device usage count Message-ID: <20180225132014.GA8844@osadl.at> References: <20180224224303.3mpwhal2axcr6aos@agrajag.zerfleddert.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180224224303.3mpwhal2axcr6aos@agrajag.zerfleddert.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 24, 2018 at 11:43:03PM +0100, Tobias Jordan wrote: > pm_runtime_get_sync() increases the device's usage count even when > reporting an error, so add a call to pm_runtime_put_noidle() in the > error branch. the increment is unconditional: pm_runtime_get_sync -> __pm_runtime_resume(dev, RPM_GET_PUT); -> if (rpmflags & RPM_GET_PUT) atomic_inc(&dev->power.usage_count); the decrement though is conditional: pm_runtime_put_noidle -> atomic_add_unless(&dev->power.usage_count, -1, 0); would it not be possible to use an atomic_dec() here rahter than atomic_add_unless() ? probably only a few cylces Also just wondering - could one not decrement in pm_runtime_get_sync on the error path rather than defering this to the caller and fixing it there ? something like: int __pm_runtime_resume(struct device *dev, int rpmflags) { ... if (rpmflags & RPM_GET_PUT) atomic_inc(&dev->power.usage_count); spin_lock_irqsave(&dev->power.lock, flags); retval = rpm_resume(dev, rpmflags); spin_unlock_irqrestore(&dev->power.lock, flags); if (retival < 0) atomic_dec(&dev->power.usage_count); return retval; } that would require other changes then I guess (did not look into it). but if resume fails does it ever make sense to increment the use count ? > > Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM") > Signed-off-by: Tobias Jordan Reviewed-by: Nicholas Mc Guire > --- > This is one of a number of patches for problems found using coccinelle > scripting in the SIL2LinuxMP project. The patch has been compile-tested; > it's based on linux-next-20180223. > > For a discussion of the corresponding issue, see > https://marc.info/?l=linux-pm&m=151904483924999&w=2 > > drivers/i2c/busses/i2c-img-scb.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c > index f038858b6c54..569a1a8a2753 100644 > --- a/drivers/i2c/busses/i2c-img-scb.c > +++ b/drivers/i2c/busses/i2c-img-scb.c > @@ -1061,8 +1061,10 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, > } > > ret = pm_runtime_get_sync(adap->dev.parent); > - if (ret < 0) > + if (ret < 0) { > + pm_runtime_put_noidle(adap->dev.parent); > return ret; > + } > > for (i = 0; i < num; i++) { > struct i2c_msg *msg = &msgs[i]; > @@ -1162,8 +1164,10 @@ static int img_i2c_init(struct img_i2c *i2c) > int ret; > > ret = pm_runtime_get_sync(i2c->adap.dev.parent); > - if (ret < 0) > + if (ret < 0) { > + pm_runtime_put_noidle(i2c->adap.dev.parent); > return ret; > + } > > rev = img_i2c_readl(i2c, SCB_CORE_REV_REG); > if ((rev & 0x00ffffff) < 0x00020200) { > -- > 2.11.0 > > _______________________________________________ > SIL2review mailing list > SIL2review@lists.osadl.org > https://lists.osadl.org/mailman/listinfo/sil2review