From: Lukas Wunner <lukas@wunner.de>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Hans de Goede <hdegoede@redhat.com>,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Wolfram Sang <wsa@the-dreams.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters
Date: Wed, 19 Dec 2018 18:22:50 +0100 [thread overview]
Message-ID: <20181219172250.ytronxeq2yc4vp4r@wunner.de> (raw)
In-Reply-To: <20181219164827.20985-2-wsa+renesas@sang-engineering.com>
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
next prev parent reply other threads:[~2018-12-19 17:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 16:48 [PATCH 00/10] i2c: move handling of suspended adapters to the core Wolfram Sang
2018-12-19 16:48 ` [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters Wolfram Sang
2018-12-19 17:22 ` Lukas Wunner [this message]
2018-12-19 18:36 ` Hans de Goede
2018-12-19 22:33 ` Wolfram Sang
2018-12-20 10:00 ` Hans de Goede
2018-12-20 21:09 ` Rafael J. Wysocki
2018-12-21 10:43 ` Hans de Goede
2018-12-21 14:50 ` Wolfram Sang
2018-12-21 18:40 ` Peter Rosin
2018-12-21 18:50 ` Wolfram Sang
2018-12-19 16:48 ` [PATCH 02/10] i2c: reject new transfers when adapters are suspended Wolfram Sang
2018-12-19 16:48 ` [PATCH 03/10] i2c: synquacer: remove unused is_suspended flag Wolfram Sang
2018-12-19 16:48 ` [PATCH 04/10] i2c: brcmstb: use core helper to mark adapter suspended Wolfram Sang
2018-12-19 16:48 ` [PATCH 05/10] i2c: zx2967: " Wolfram Sang
2018-12-19 16:48 ` [PATCH 06/10] i2c: sprd: don't use pdev as variable name for struct device * Wolfram Sang
2018-12-21 8:58 ` Baolin Wang
2018-12-19 16:48 ` [PATCH 07/10] i2c: sprd: use core helper to mark adapter suspended Wolfram Sang
2018-12-21 9:03 ` Baolin Wang
2018-12-19 16:48 ` [PATCH 08/10] i2c: exynos5: " Wolfram Sang
2018-12-19 16:48 ` [PATCH 09/10] i2c: s3c2410: " Wolfram Sang
2018-12-19 16:48 ` [PATCH 10/10] i2c: rcar: add suspend/resume support Wolfram Sang
2019-01-08 20:09 ` [PATCH 00/10] i2c: move handling of suspended adapters to the core Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181219172250.ytronxeq2yc4vp4r@wunner.de \
--to=lukas@wunner.de \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).