Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5416776imu; Wed, 19 Dec 2018 10:43:57 -0800 (PST) X-Google-Smtp-Source: AFSGD/WQ1chKBjBrba61uS8R3/1ybXI/bhjzrdfFORiJcPxPftA6bWmMw7v90sMhvDB8nlAxkoKb X-Received: by 2002:a62:34c6:: with SMTP id b189mr22069150pfa.229.1545245036946; Wed, 19 Dec 2018 10:43:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545245036; cv=none; d=google.com; s=arc-20160816; b=gKIfWZF4wpFeM+rPXMwvgoZ5mgr/xnPBwyNV3a/B2wvP8VIoWBuukEVP59eRubLhVN 28p6XhYc8PHVaDYeTKeiX4Cf6o0QAplWThmgk498nP1l1m2xlJTW2UuP1xN2TS5Catnd oG+gZk1A8mpAwFUWndG3IVX7aU+KQaPBe+0DVI5eJKc8gmRJ2w+vDXmy2OvNBq3VnE25 Wt2mNuJDkInucOVWRPg+mNls0BcesIk1jOP6zlWQMK0V+AK3vSCsTU8Tc3YjjkUo2NC5 fquYYZqOWusvBcxAWKG8F6dTya8cvpQMplMO7xpsCLPpNqeBafZVQdoZuATTEUjPkJR9 RQJw== 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; bh=3HYMjSupGyT/JLx1ptGZ0UE1/xjXhgXk7/mEOuIDY0E=; b=SS0sV5aS9lnVtnVGVgPaq7kh5/JHPpITrmxZfNx2S9ZswhHHPx9r3PCPNGyT5viacv ScAbBG7uMpT/rsFWF42Xblbvx2nuFytR2Cxum1hq+3OO8qHcbe12itmX/ewiiw0+wUGJ nmRc0DWqtflWBv+cjWfkHsbPwdoZXr6I3gvZDKMQ23eegHRDssoH3pXJrDg8k8SGqpkW DPKj2YVakClxhG7uLoQ+McYhU2R+VjqE20usgqbzdLBUK38eOwahJHTaZGMUxtkBgCK1 NZtZRZ02mqrcwT32hYJmDdCQDSfjJGHI9MXVVG7oxjHUNYDdYXYxtRylfspTRS4LmPFE Dx9A== 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 t77si15986149pgb.51.2018.12.19.10.43.41; Wed, 19 Dec 2018 10:43:56 -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 S1730375AbeLSRWx (ORCPT + 99 others); Wed, 19 Dec 2018 12:22:53 -0500 Received: from bmailout2.hostsharing.net ([83.223.90.240]:49157 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727716AbeLSRWx (ORCPT ); Wed, 19 Dec 2018 12:22:53 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 5034428011B88; Wed, 19 Dec 2018 18:22:51 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 0C4A01D378B; Wed, 19 Dec 2018 18:22:51 +0100 (CET) Date: Wed, 19 Dec 2018 18:22:50 +0100 From: Lukas Wunner To: Wolfram Sang Cc: linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Hans de Goede , linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Wolfram Sang , linux-kernel@vger.kernel.org Subject: Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters Message-ID: <20181219172250.ytronxeq2yc4vp4r@wunner.de> References: <20181219164827.20985-1-wsa+renesas@sang-engineering.com> <20181219164827.20985-2-wsa+renesas@sang-engineering.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181219164827.20985-2-wsa+renesas@sang-engineering.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 19, 2018 at 05:48:17PM +0100, Wolfram Sang wrote: > +static inline void i2c_mark_adapter_suspended(struct i2c_adapter *adap) > +{ > + i2c_lock_bus(adap, I2C_LOCK_ROOT_ADAPTER); > + set_bit(I2C_ALF_IS_SUSPENDED, &adap->locked_flags); > + i2c_unlock_bus(adap, I2C_LOCK_ROOT_ADAPTER); > +} This looks like a duplication of the is_suspended flag in struct dev_pm_info. Any reason why you can't use that? If so, it would be good to document the reason in the commit message. If the point is to constrain refusal of transfers in suspended state to certain drivers, those drivers could opt in to that functionality by setting a flag, and the i2c core could then gate refusal based on that flag and the is_suspended flag in struct dev_pm_info. Also, why is it necessary to take a lock to perform an atomic bitop? (Sorry if that's a dumb question, seems non-obvious to me.) Thanks, Lukas