All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Kevin Hilman <khilman@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Philipp Zabel <philipp.zabel@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Wolfram Sang <wsa@the-dreams.de>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	Chris Ball <chris@printf.net>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>,
	Alan Stern <stern@rowland.harvard.edu>,
	Mark Brown <broonie@kernel.org>, Ben Dooks <ben-linux@f>
Subject: Re: [v4,1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code
Date: Fri, 19 Sep 2014 01:13:21 +0200	[thread overview]
Message-ID: <58813810.nrS47mt5xk@vostro.rjw.lan> (raw)
In-Reply-To: <CAPDyKFoPBfAYfP9gwSxWvdUvNSjMxxNeJ_BfRkgvOZLTNpzJXA@mail.gmail.com>

On Thursday, September 18, 2014 02:35:44 AM Ulf Hansson wrote:
> On 18 September 2014 01:43, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
> >> On 17 September 2014 22:10, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >> > 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.
> >>
> >> OK!
> >>
> >> >
> >> >>
> >> >> >
> >> >> >> 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.
> >>
> >> No, that's not needed. Go ahead and have look at both ACPI and genpd,
> >> the interesting part is the validation of struct dev_pm_domain pointer
> >> in the struct device. That's all there is to it, no additional data
> >> are required.
> >
> > OK, so can you simply put the needed method into struct dev_pm_domain and then
> > dev_pm_domain_detach() would become:
> >
> > void dev_pm_domain_detach(struct device *dev, bool power_off)
> > {
> >         if (dev->pm_domain)
> >                 dev->pm_domain->detach(dev, power_off);
> > }
> >
> > Thanks.
> 
> Ohh, didn't quite follow that this is what you meant. That would be a
> great improvement, I will adopt in the next version.


         if (dev->pm_domain && dev->pm_domain->detach)
                 dev->pm_domain->detach(dev, power_off);


Pretty please.

Rafael


WARNING: multiple messages have this Message-ID (diff)
From: rjw@rjwysocki.net (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [v4, 1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code
Date: Fri, 19 Sep 2014 01:13:21 +0200	[thread overview]
Message-ID: <58813810.nrS47mt5xk@vostro.rjw.lan> (raw)
In-Reply-To: <CAPDyKFoPBfAYfP9gwSxWvdUvNSjMxxNeJ_BfRkgvOZLTNpzJXA@mail.gmail.com>

On Thursday, September 18, 2014 02:35:44 AM Ulf Hansson wrote:
> On 18 September 2014 01:43, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> > On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
> >> On 17 September 2014 22:10, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> >> > 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.
> >>
> >> OK!
> >>
> >> >
> >> >>
> >> >> >
> >> >> >> 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.
> >>
> >> No, that's not needed. Go ahead and have look at both ACPI and genpd,
> >> the interesting part is the validation of struct dev_pm_domain pointer
> >> in the struct device. That's all there is to it, no additional data
> >> are required.
> >
> > OK, so can you simply put the needed method into struct dev_pm_domain and then
> > dev_pm_domain_detach() would become:
> >
> > void dev_pm_domain_detach(struct device *dev, bool power_off)
> > {
> >         if (dev->pm_domain)
> >                 dev->pm_domain->detach(dev, power_off);
> > }
> >
> > Thanks.
> 
> Ohh, didn't quite follow that this is what you meant. That would be a
> great improvement, I will adopt in the next version.


         if (dev->pm_domain && dev->pm_domain->detach)
                 dev->pm_domain->detach(dev, power_off);


Pretty please.

Rafael

  reply	other threads:[~2014-09-18 23:13 UTC|newest]

Thread overview: 96+ 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 ` 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-09-04 13:52   ` Ulf Hansson
2014-08-23 22:45   ` Pavel Machek
2014-08-23 22:45     ` Pavel Machek
2014-09-07 22:12   ` Rafael J. Wysocki
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-04 13:52   ` Ulf Hansson
2014-09-07 22:13   ` Rafael J. Wysocki
2014-09-07 22:13     ` Rafael J. Wysocki
2014-09-08  7:26     ` Ulf Hansson
2014-09-08  7:26       ` Ulf Hansson
2014-09-08 21:04       ` Rafael J. Wysocki
2014-09-08 21:04         ` Rafael J. Wysocki
2014-09-08 21:08         ` Rafael J. Wysocki
2014-09-08 21:08           ` Rafael J. Wysocki
2014-09-08 20:53           ` Geert Uytterhoeven
2014-09-08 20:53             ` Geert Uytterhoeven
     [not found]             ` <CAMuHMdURbp8a0Ps2sZUZn7UHcWXZvRgS-4ubk1r=wGgXZ1PHmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-08 21:26               ` Rafael J. Wysocki
2014-09-08 21:26                 ` Rafael J. Wysocki
2014-09-09 11:40                 ` Mark Brown
2014-09-09 11:40                   ` Mark Brown
2014-09-09 13:45                   ` Rafael J. Wysocki
2014-09-09 13:45                     ` Rafael J. Wysocki
2014-09-08 20:53           ` Tomasz Figa
2014-09-08 20:53             ` Tomasz Figa
2014-09-09  7:04         ` Ulf Hansson
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-04 13:52   ` Ulf Hansson
2014-09-08 22:11   ` Rafael J. Wysocki
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   ` Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 5/9] i2c: core: " Ulf Hansson
2014-09-04 13:52   ` Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 6/9] mmc: sdio: " Ulf Hansson
2014-09-04 13:52   ` Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 7/9] spi: core: " Ulf Hansson
2014-09-04 13:52   ` 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   ` Ulf Hansson
2014-09-04 13:52 ` [PATCH v3 9/9] ARM: exynos: Move to generic PM domain DT bindings Ulf Hansson
2014-09-04 13:52   ` Ulf Hansson
2014-09-05 15:39 ` [PATCH v3 0/9] PM / Domains: Generic OF-based support Kevin Hilman
2014-09-05 15:39   ` Kevin Hilman
2014-09-09 11:36 ` [PATCH v4 " Ulf Hansson
2014-09-09 11:36   ` 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-09 11:36     ` Ulf Hansson
2014-09-12 21:05     ` [v4,1/9] " Dmitry Torokhov
2014-09-12 21:05       ` [v4, 1/9] " Dmitry Torokhov
2014-09-14 16:38       ` [v4,1/9] " Rafael J. Wysocki
2014-09-14 16:38         ` [v4, 1/9] " Rafael J. Wysocki
2014-09-15 16:53         ` [v4,1/9] " Dmitry Torokhov
2014-09-15 16:53           ` [v4, 1/9] " Dmitry Torokhov
2014-09-15 23:36           ` [v4,1/9] " Rafael J. Wysocki
2014-09-15 23:36             ` [v4, 1/9] " Rafael J. Wysocki
2014-09-17 18:25             ` [v4,1/9] " Ulf Hansson
2014-09-17 18:25               ` [v4, 1/9] " Ulf Hansson
2014-09-17 20:10               ` [v4,1/9] " Dmitry Torokhov
2014-09-17 20:10                 ` [v4, 1/9] " Dmitry Torokhov
2014-09-17 23:20                 ` [v4,1/9] " Ulf Hansson
2014-09-17 23:20                   ` [v4, 1/9] " Ulf Hansson
2014-09-17 23:43                   ` [v4,1/9] " Dmitry Torokhov
2014-09-17 23:43                     ` [v4, 1/9] " Dmitry Torokhov
     [not found]                     ` <20140917234331.GA28771-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2014-09-18  0:35                       ` [v4,1/9] " Ulf Hansson
2014-09-18  0:35                         ` [v4, 1/9] " Ulf Hansson
2014-09-18 23:13                         ` Rafael J. Wysocki [this message]
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     ` 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     ` 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 11:36     ` Ulf Hansson
2014-09-09 13:46     ` Rafael J. Wysocki
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     ` Ulf Hansson
2014-09-09 11:36   ` [PATCH v4 6/9] mmc: sdio: " Ulf Hansson
2014-09-09 11:36     ` Ulf Hansson
2014-09-09 11:36   ` [PATCH v4 7/9] spi: core: " Ulf Hansson
2014-09-09 11:36     ` 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     ` 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:36     ` Ulf Hansson
2014-09-09 11:43   ` [PATCH v4 0/9] PM / Domains: Generic OF-based support Tomasz Figa
2014-09-09 11:43     ` Tomasz Figa
2014-09-09 11:54   ` Mark Brown
2014-09-09 11:54     ` Mark Brown
2014-09-09 12:45     ` Ulf Hansson
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=58813810.nrS47mt5xk@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=ben-linux@f \
    --cc=broonie@kernel.org \
    --cc=chris@printf.net \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@verge.net.au \
    --cc=khilman@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=philipp.zabel@gmail.com \
    --cc=sboyd@codeaurora.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tomasz.figa@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.