From: dmitry.torokhov@gmail.com (Dmitry Torokhov)
To: linux-arm-kernel@lists.infradead.org
Subject: [v4, 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code
Date: Wed, 17 Sep 2014 13:10:25 -0700 [thread overview]
Message-ID: <20140917201025.GC25297@core.coreip.homeip.net> (raw)
In-Reply-To: <CAPDyKFq6FZcuU=TCMh0JE0ymbS73_eLtNrTgmgKA4OxEp=_zpw@mail.gmail.com>
On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
> On 16 September 2014 01:36, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Monday, September 15, 2014 09:53:59 AM Dmitry Torokhov wrote:
> >> On Sun, Sep 14, 2014 at 06:38:58PM +0200, Rafael J. Wysocki wrote:
> >> > On Friday, September 12, 2014 02:05:53 PM Dmitry Torokhov wrote:
> >> > > Hi Ulf,
> >> > >
> >> > > On Tue, Sep 09, 2014 at 01:36:02PM +0200, Ulf Hansson wrote:
> >> > > > To give callers the option of acting on a errors while removing the
> >> > > > pm_domain ops for the device in the ACPI PM domain, let
> >> > > > acpi_dev_pm_detach() return an int to provide the error code.
> >> > >
> >> > > So how would callers handle the errors? As far as I can see
> >> > > acpi_dev_pm_detach() is called from ->remove() and ->shutdown() methods, where
> >> > > there is no meaningful strategy to handle errors as you are past the point of
> >> > > no return and you keep on tearing down the device.
>
> The benefit is only relevant when ACPI and genpd PM domains would
> co-exist. In that case we might be able to skip genpd_dev_pm_detach()
> if acpi_dev_pm_detach() succeeds. So, currently there are no benefit,
> but still it doesn't hurt.
It doe snot have any negative material effect, the drawback is purely
from API perspective.
>
> >> >
> >> > This is specifically for what patch [3/9] is doing AFAICS.
> >> >
> >> > The existing callers don't need to worry about this.
> >>
> >> OK, so I have the very same comment about patch 3 then: we have
> >> dev_pm_domain_detach() returning error. How would the callers handle errors?
> >
> > Ulf?
>
> I see your point. How about making dev_pm_domain_detach() to be a void
> function instead?
Yes, please.
>
> >
> >> WRT this patch: I'd rater we did not just return generic "error code" just
> >> because we do not know who manages PD for the device. Can we add API to check
> >> if we are using ACPI to manage power domains? Then patch #3 could check if it
> >> needs to use ACPI or generic power domain API.
>
> The problem is scalability. If we have other PM domains implementation
> in future, each of them need to be checked prior invoking the attach
> functions.
> Also, how would we distinguish between genpd and a new PM domain XYZ?
I do not think that trying all available methods to detach a pm domain,
i.e.
err = acpi_dev_pm_detach();
if (err)
err = blah_dev_pm_detach();
if (err)
err = flab_dev_pm_detach();
if (err)
err = gen_dev_pm_detach();
is any better from scalability point of view. If you need to do that you
will probably have to store something like "struct pd_ops *pd_ops" in
your device and call appropriate implementation via it.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2014-09-17 20:10 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 13:52 [PATCH v3 0/9] PM / Domains: Generic OF-based support Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code Ulf Hansson
2014-08-23 22:45 ` Pavel Machek
2014-09-07 22:12 ` Rafael J. Wysocki
2014-09-04 13:52 ` [PATCH v3 2/9] PM / Domains: Add generic OF-based PM domain look-up Ulf Hansson
2014-09-07 22:13 ` Rafael J. Wysocki
2014-09-08 7:26 ` Ulf Hansson
2014-09-08 21:04 ` Rafael J. Wysocki
2014-09-08 21:08 ` Rafael J. Wysocki
2014-09-08 20:53 ` Geert Uytterhoeven
2014-09-08 21:26 ` Rafael J. Wysocki
2014-09-09 11:40 ` Mark Brown
2014-09-09 13:45 ` Rafael J. Wysocki
2014-09-08 20:53 ` Tomasz Figa
2014-09-09 7:04 ` Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 3/9] PM / Domains: Add APIs to attach/detach a PM domain for a device Ulf Hansson
2014-09-08 22:11 ` Rafael J. Wysocki
2014-09-04 13:52 ` [PATCH v3 4/9] drivercore / platform: Convert to dev_pm_domain_attach|detach() Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 5/9] i2c: core: " Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 6/9] mmc: sdio: " Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 7/9] spi: core: " Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 8/9] amba: Add support for attach/detach of PM domains Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 9/9] ARM: exynos: Move to generic PM domain DT bindings Ulf Hansson
2014-09-05 15:39 ` [PATCH v3 0/9] PM / Domains: Generic OF-based support Kevin Hilman
2014-09-09 11:36 ` [PATCH v4 " Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code Ulf Hansson
2014-09-12 21:05 ` [v4, " Dmitry Torokhov
2014-09-14 16:38 ` Rafael J. Wysocki
2014-09-15 16:53 ` Dmitry Torokhov
2014-09-15 23:36 ` Rafael J. Wysocki
2014-09-17 18:25 ` Ulf Hansson
2014-09-17 20:10 ` Dmitry Torokhov [this message]
2014-09-17 23:20 ` Ulf Hansson
2014-09-17 23:43 ` Dmitry Torokhov
2014-09-18 0:35 ` Ulf Hansson
2014-09-18 23:13 ` Rafael J. Wysocki
2014-09-09 11:36 ` [PATCH v4 2/9] PM / Domains: Add generic OF-based PM domain look-up Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 3/9] PM / Domains: Add APIs to attach/detach a PM domain for a device Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 4/9] drivercore / platform: Convert to dev_pm_domain_attach|detach() Ulf Hansson
2014-09-09 13:46 ` Rafael J. Wysocki
2014-09-09 11:36 ` [PATCH v4 5/9] i2c: core: " Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 6/9] mmc: sdio: " Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 7/9] spi: core: " Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 8/9] amba: Add support for attach/detach of PM domains Ulf Hansson
2014-09-09 11:36 ` [PATCH v4 9/9] ARM: exynos: Move to generic PM domain DT bindings Ulf Hansson
2014-09-09 11:43 ` [PATCH v4 0/9] PM / Domains: Generic OF-based support Tomasz Figa
2014-09-09 11:54 ` Mark Brown
2014-09-09 12:45 ` Ulf Hansson
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=20140917201025.GC25297@core.coreip.homeip.net \
--to=dmitry.torokhov@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).