From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Mårten Lindahl" <marten.lindahl@axis.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
linux-iio@vger.kernel.org, kernel@axis.com
Subject: Re: [PATCH] iio: light: vcnl4000: Don't create sysfs PM nodes for child
Date: Mon, 7 Nov 2022 17:08:57 +0000 [thread overview]
Message-ID: <20221107170857.00002464@Huawei.com> (raw)
In-Reply-To: <20221107103636.bua6xd5tghuisddb@bogus>
On Mon, 7 Nov 2022 10:36:36 +0000
Sudeep Holla <sudeep.holla@arm.com> wrote:
> On Sun, Nov 06, 2022 at 03:23:07PM +0000, Jonathan Cameron wrote:
> > On Tue, 1 Nov 2022 13:21:51 +0100
> > Mårten Lindahl <marten.lindahl@axis.com> wrote:
> >
> > > PM runtime is enabled for the parent i2c device, but it is disabled for
> > > the iio child device and remains so in this driver. But as the child
> > > sysfs PM directory is created by default by iio_device_register =>
> > > cdev_device_add => dpm_sysfs_add it doesn't bring any value exposing it
> > > since it won't give any usable data for the user.
> > >
> > > Tell dpm_sysfs to not create the PM directory for the iio device.
> > >
> > > Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
> >
> > Ah this one.. +CC Sudeep who I am sure has considered such changes in other
> > similar cases (he did the original ones that mean this infastructure exists).
> >
>
> Yes it was added for cache devices which are child devices of CPU devices via
> Commit 85945c28b5a8 ("PM / core: Add support to skip power management in device/driver model")
>
> Since CPU and its children are power managed quite differently(via cpuidle
> or cpu hotplug), the new API(device_set_pm_not_required) fits the usecase
> there well. I am not sure about this IIO usecase.
>
These are effectively pseudo devices for purposes of the driver model, with parents
as the actual physical devices. As such all the PM infrastructure is associate
with the appropriate bus specific device rather than the struct iio_dev->dev.
So I'm fairly sure we should just not expose the sysfs attributes.
This is similar to CXL for which they are only exposed for the PCI devices, not
the bunch of subdevices created.
Jonathan
next prev parent reply other threads:[~2022-11-07 17:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 12:21 [PATCH] iio: light: vcnl4000: Don't create sysfs PM nodes for child Mårten Lindahl
2022-11-06 15:23 ` Jonathan Cameron
2022-11-07 7:22 ` Marten Lindahl
2022-11-07 10:36 ` Sudeep Holla
2022-11-07 17:08 ` Jonathan Cameron [this message]
2022-11-07 17:14 ` Sudeep Holla
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=20221107170857.00002464@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=jic23@kernel.org \
--cc=kernel@axis.com \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=marten.lindahl@axis.com \
--cc=sudeep.holla@arm.com \
/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