From: Nicolin Chen <nicoleotsuka@gmail.com>
To: linux@roeck-us.net
Cc: jdelvare@suse.com, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] hwmon: (core) Inherit power properties to hdev
Date: Wed, 24 Oct 2018 18:01:17 -0700 [thread overview]
Message-ID: <20181025010116.GA4543@Asurada-Nvidia.nvidia.com> (raw)
In-Reply-To: <20181025001301.Horde.VCevVrrSs6rOyXT41xiPOzW@cp2.active-venture.com>
On Thu, Oct 25, 2018 at 12:13:01AM +0000, linux@roeck-us.net wrote:
> > + if (dev) {
> > + hdev->driver = dev->driver;
> > + hdev->power = dev->power;
> > + hdev->pm_domain = dev->pm_domain;
> > + hdev->of_node = dev->of_node;
> > + }
>
> We'l need to dig into this more; I suspect it may be inappropriate to do this.
> With this change, every hwmon driver supporting (runtime ?) suspend/resume
> will have the problem worked around in #5, and that just seems wrong.
Hmm..that's true...thanks for catching it.
Actually I am not sure the reason of having a child device in
the core, but could we use the parent dev pointer in the hwmon
core as hwmon_dev upon confirming parent dev pointer != NULL?
The problem here is that the power directory under each hwmon
directory is tied to the hwmon_dev pointer, not to the parent
dev pointer, and the hwmon core creates all sysfs nodes based
on the child node. So those nodes under power directory won't
be valid unless we copy all pm information, especially PM ops.
There is an option of ignoring this problem though, while all
hwmon drivers will need to be careful of mixing using the dev
pointers. So it'd be a lot of easier if we could just use the
original dev pointer in the core since we mainly just need to
create sysfs nodes.
Another way of doing this might be to pass down the PM pointer
via _info structure instead of linking it to the parent driver,
which then will forbid all hwmon drivers having its own PM ops
callbacks -- the very opposite way of this patch, and it does
not sound fully reasonable and feasible to me...
What do you think about?
Thanks
Nicolin
next prev parent reply other threads:[~2018-10-25 1:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-24 19:33 [PATCH v3 0/5] hwmon: (ina3221) Implement PM runtime to save power Nicolin Chen
2018-10-24 19:33 ` [PATCH v3 1/5] hwmon: (core) Inherit power properties to hdev Nicolin Chen
2018-10-25 0:13 ` linux
2018-10-25 1:01 ` Nicolin Chen [this message]
2018-10-25 1:33 ` Nicolin Chen
2018-10-25 6:55 ` linux
2018-10-25 23:21 ` Nicolin Chen
2018-10-24 19:33 ` [PATCH v3 2/5] hwmon: (ina3221) Check channel status for alarms attribute read Nicolin Chen
2018-10-24 19:34 ` [PATCH v3 3/5] hwmon: (ina3221) Serialize sysfs ABI accesses Nicolin Chen
2018-10-24 19:34 ` [PATCH v3 4/5] hwmon: (ina3221) Make sure data is ready before reading Nicolin Chen
2018-10-24 19:34 ` [PATCH v3 5/5] hwmon: (ina3221) Add PM runtime support Nicolin Chen
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=20181025010116.GA4543@Asurada-Nvidia.nvidia.com \
--to=nicoleotsuka@gmail.com \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/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).