Received: by 10.223.185.116 with SMTP id b49csp3566523wrg; Mon, 26 Feb 2018 02:09:16 -0800 (PST) X-Google-Smtp-Source: AH8x224M6gJQIlh074TWsZM9NfWliiYaSRG3sMt13ZszzWbjZ7Bl5mCNuA3H8PLZz7fDNYYpu3OB X-Received: by 2002:a17:902:536a:: with SMTP id b97-v6mr10069429pli.421.1519639756280; Mon, 26 Feb 2018 02:09:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519639756; cv=none; d=google.com; s=arc-20160816; b=iUbFP9cDGWhrdsXUt/V1zYvwvyfyayVGjh4aBcm3Ah7cZ4JimAnBBC9TrAzr0delIG ttCYgYMpgyoYB36j7wp4zCkdSHr47GZj4SPO+/rzZpGYAY+XVLD1BhAqEXWXMzuTuD5l eM2tCp150NZD0VDb21oRUbAChznaInHALNNgct2wZRRMopeT0in7BPcTe3UB38BWwsXV mFGtBTRyaJ8ZX+EOD5aWcMft/A5ZEdkGkMAWw8NZf8uU96v9h2L6DBsMpF8mXOzybNCC UFvSBTeIsK/kp4QWoij5Oh+Ri9AchiO9NPN4yh2LvZ76WFF8k9bAXFN29l1MrGI74kC6 fD8g== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=2bGymkOWoYL9B/rFG2OH7vmsnlm/tMOzWMMnNfvSg6Y=; b=HxvlHSIa12My5KuC0Q0Mv356uOvSsVGlE+MWixpqm9/GXMcRze70lT3gbNScKjPuMG w7WlavW95gJ8Czkat83TAEYP7iOZ4fZePPxpSeIzmuMJffe67+ibCY1A7kUorGMaB8Wq /RMRMfdLyswxSNFiyyd7jpYR81/kHMGHNqDzwvhz04oWx2dQkK5kGpW5gRTHxV4eUhmb YPsNiGa86vz1FAJoz7h8HmKmeJKb+OYC93EWNV+/NfIoPplZxZau/5bl7HDsy0vLFNX4 4BvgVO1+SnFunkAlI32CkRgw9GEkzrlmQl8T/otfwZcvIHvwCn/K16OTb5r7VcfChLW0 qkXA== 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 c66si6518596pfc.416.2018.02.26.02.09.01; Mon, 26 Feb 2018 02:09:16 -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 S1752456AbeBZKHk convert rfc822-to-8bit (ORCPT + 99 others); Mon, 26 Feb 2018 05:07:40 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:62533 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbeBZKHj (ORCPT ); Mon, 26 Feb 2018 05:07:39 -0500 Received: from 79.184.254.228.ipv4.supernova.orange.pl (79.184.254.228) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id d46ff3f4f9d7bff0; Mon, 26 Feb 2018 11:07:37 +0100 From: "Rafael J. Wysocki" To: Uwe =?ISO-8859-1?Q?Kleine=2DK=F6nig?= Cc: Tobias Jordan , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Wolfram Sang Subject: Re: [PATCH] i2c: imx: Fix PM device usage count Date: Mon, 26 Feb 2018 11:08:29 +0100 Message-ID: <31679751.ihdXrgd1zD@aspire.rjw.lan> In-Reply-To: <20180225195748.5itrchj36wz5mquu@pengutronix.de> References: <20180224224328.2pfki7rqcxqetmlz@agrajag.zerfleddert.de> <20180225195748.5itrchj36wz5mquu@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sunday, February 25, 2018 8:57:48 PM CET Uwe Kleine-K?nig wrote: > On Sat, Feb 24, 2018 at 11:43:28PM +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 > > related error branches. > > > > Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the > > performance") > > Signed-off-by: Tobias Jordan > > --- > > In i2c_imx_xfer(), one could also move the "out" label up (in front of > > the call to pm_runtime_put_autosuspend()), but I'm not sure what the > > underlying error scenario is; calling _put_noidle() seems to be the > > safer bet. > > > > 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 > > I don't get the original mail, so reply here. In reply to the question I > would have asked here, too: > > > Why isn't ...get_sync() directly calling ...put_noidle() but relies on > > the driver implementation to do it? It seems unintuitive for a _get_ > > function to increase the usage count although returning an error. > > Rafael replied: > > > Because ...get_sync() returns an error when runtime PM is disabled and > > we wanted that case to be transparent for the users of it. > > > > In the majority of cases (if not always) errors returned by > > ...get_sync() > > mean disabled runtime PM or flaky hardware and the latter is much less > > common (and generally there's not much to do about them in the kernel > > anyway). > > If pm_runtime_get_sync() should be transparent for the users if PM is > disable, why not simply return success then? Because *some* users of it want to get the error. They generally need to handle the rumtime PM disabled situation differently. Thanks, Rafael