[v4,1/9] ACPI / PM: Let acpi_dev_pm_detach() return an error code

Commit Message

Ulf Hansson Sept. 9, 2014, 11:36 a.m. UTC

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.

Signed-off-by: Ulf Hansson <[e-mail]>
Tested-by: Philipp Zabel <[e-mail]>
Acked-by: Pavel Machek <[e-mail]>
Reviewed-by: Kevin Hilman <[e-mail]>
---
 drivers/acpi/device_pm.c | 8 +++++++-
 include/linux/acpi.h     | 7 +++++--
 2 files changed, 12 insertions(+), 3 deletions(-)

Comments

Dmitry Torokhov Sept. 12, 2014, 9:05 p.m. UTC | #1

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.

Thanks.

Rafael J. Wysocki Sept. 14, 2014, 4:38 p.m. UTC | #2

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.

This is specifically for what patch [3/9] is doing AFAICS.  

The existing callers don't need to worry about this.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov Sept. 15, 2014, 4:53 p.m. UTC | #3

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.
> 
> 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?

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.

Thanks.

Rafael J. Wysocki Sept. 15, 2014, 11:36 p.m. UTC | #4

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.
> > 
> > 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?

> 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 rule is that if there is an ACPI companion object for the given device, then
ACPI is used.  So the API is ACPI_COMPANION(dev) and we have that check around
until someone realized that acpi_dev_pm_attach/detach() made it too.  We can
restore it, I suppose, but I'm not sure how much better it is going to be.

Either way, I have no strong preferences here.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ulf Hansson Sept. 17, 2014, 6:25 p.m. UTC | #5

On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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.

>> >
>> > 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?

>
>> 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?

Kind regards
Uffe

>
> The rule is that if there is an ACPI companion object for the given device, then
> ACPI is used.  So the API is ACPI_COMPANION(dev) and we have that check around
> until someone realized that acpi_dev_pm_attach/detach() made it too.  We can
> restore it, I suppose, but I'm not sure how much better it is going to be.
>
> Either way, I have no strong preferences here.
>
> Rafael
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov Sept. 17, 2014, 8:10 p.m. UTC | #6

On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
> On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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.

Ulf Hansson Sept. 17, 2014, 11:20 p.m. UTC | #7

On 17 September 2014 22:10, Dmitry Torokhov <[e-mail]> wrote:
> On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
>> On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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.

Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dmitry Torokhov Sept. 17, 2014, 11:43 p.m. UTC | #8

On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
> On 17 September 2014 22:10, Dmitry Torokhov <[e-mail]> wrote:
> > On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
> >> On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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.

Ulf Hansson Sept. 18, 2014, 12:35 a.m. UTC | #9

On 18 September 2014 01:43, Dmitry Torokhov <[e-mail]> wrote:
> On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
>> On 17 September 2014 22:10, Dmitry Torokhov <[e-mail]> wrote:
>> > On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
>> >> On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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.

Kind regards
Uffe

>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki Sept. 18, 2014, 11:13 p.m. UTC | #10

On Thursday, September 18, 2014 02:35:44 AM Ulf Hansson wrote:
> On 18 September 2014 01:43, Dmitry Torokhov <[e-mail]> wrote:
> > On Thu, Sep 18, 2014 at 01:20:49AM +0200, Ulf Hansson wrote:
> >> On 17 September 2014 22:10, Dmitry Torokhov <[e-mail]> wrote:
> >> > On Wed, Sep 17, 2014 at 08:25:44PM +0200, Ulf Hansson wrote:
> >> >> On 16 September 2014 01:36, Rafael J. Wysocki <[e-mail]> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 67075f8..0d52ce1 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -1055,6 +1055,8 @@  static struct dev_pm_domain acpi_general_pm_domain = {
  *
  * Callers must ensure proper synchronization of this function with power
  * management callbacks.
+ *
+ * Returns 0 on successfully attached PM domain or negative error code.
  */
 int acpi_dev_pm_attach(struct device *dev, bool power_on)
 {
@@ -1087,8 +1089,10 @@  EXPORT_SYMBOL_GPL(acpi_dev_pm_attach);
  *
  * Callers must ensure proper synchronization of this function with power
  * management callbacks.
+ *
+ * Returns 0 on successfully detached PM domain or negative error code.
  */
-void acpi_dev_pm_detach(struct device *dev, bool power_off)
+int acpi_dev_pm_detach(struct device *dev, bool power_off)
 {
 	struct acpi_device *adev = ACPI_COMPANION(dev);
 
@@ -1107,7 +1111,9 @@  void acpi_dev_pm_detach(struct device *dev, bool power_off)
 			acpi_device_wakeup(adev, ACPI_STATE_S0, false);
 			acpi_dev_pm_low_power(dev, adev, ACPI_STATE_S0);
 		}
+		return 0;
 	}
+	return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(acpi_dev_pm_detach);
 #endif /* CONFIG_PM */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 807cbc4..c83cca5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -587,7 +587,7 @@  static inline int acpi_subsys_freeze(struct device *dev) { return 0; }
 #if defined(CONFIG_ACPI) && defined(CONFIG_PM)
 struct acpi_device *acpi_dev_pm_get_node(struct device *dev);
 int acpi_dev_pm_attach(struct device *dev, bool power_on);
-void acpi_dev_pm_detach(struct device *dev, bool power_off);
+int acpi_dev_pm_detach(struct device *dev, bool power_off);
 #else
 static inline struct acpi_device *acpi_dev_pm_get_node(struct device *dev)
 {
@@ -597,7 +597,10 @@  static inline int acpi_dev_pm_attach(struct device *dev, bool power_on)
 {
 	return -ENODEV;
 }
-static inline void acpi_dev_pm_detach(struct device *dev, bool power_off) {}
+static inline int acpi_dev_pm_detach(struct device *dev, bool power_off)
+{
+	return -ENODEV;
+}
 #endif
 
 #ifdef CONFIG_ACPI