[PATCH] usb: musb: fix pm_runtime mismatch

[PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Contreras]

In musb_init_controller() there's a pm_runtime_put(), but there's no
pm_runtime_get(), which creates a mismatch that causes the driver to
sleep when it shouldn't.

This was introduced in 7acc619, but it wasn't triggered until 18a2689
was merged to Linus' branch at point 6899608.

However, it seems most of the time this is used in a way that keeps the
counter above 0, so nobody noticed. Also, it seems to depend on the
configuration used.

I found the problem by loading isp1704_charger before any usb gadgets:
http://article.gmane.org/gmane.linux.kernel/1226122

All versions after 2.6.39 are affected.

Cc: stable@vger.kernel.org
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 drivers/usb/musb/musb_core.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b63ab15..920f04e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 	if (status < 0)
 		goto fail3;
 
-	pm_runtime_put(musb->controller);
-
 	status = musb_init_debugfs(musb);
 	if (status < 0)
 		goto fail4;
-- 
1.7.8.rc1.14.g248db

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

Hi,

On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> In musb_init_controller() there's a pm_runtime_put(), but there's no
> pm_runtime_get(), which creates a mismatch that causes the driver to
> sleep when it shouldn't.
> 
> This was introduced in 7acc619, but it wasn't triggered until 18a2689
> was merged to Linus' branch at point 6899608.

you need to add the commit description (whatever was the mail's subject)
here too. And you should put in Cc the author or those commits too,
otherwise we can't poke into their brains to understand what they were
thinking when they originally wrote those patches.

> However, it seems most of the time this is used in a way that keeps the
> counter above 0, so nobody noticed. Also, it seems to depend on the
> configuration used.
> 
> I found the problem by loading isp1704_charger before any usb gadgets:
> http://article.gmane.org/gmane.linux.kernel/1226122
> 
> All versions after 2.6.39 are affected.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/usb/musb/musb_core.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index b63ab15..920f04e 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
>  	if (status < 0)
>  		goto fail3;
>  
> -	pm_runtime_put(musb->controller);

To me the real fix would be add the missing pm_runtime_get_sync(). On
probe() we're actually accessing MUSB's address space which needs it's
clocks turned on. I guess it's only working now by chance, probably
because glue layer calls pm_runtime_get_sync() to access it's own
address space and that uses the same clocks.

Hema, since this was introduced by a patch of yours, care to check this
patch ? You _do_ say on your original commit that pm_runtime_get_sync()
is called during probe, but you're not doing so. Was that just a mistake
on the original commit ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Greg KH]

On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> In musb_init_controller() there's a pm_runtime_put(), but there's no
> pm_runtime_get(), which creates a mismatch that causes the driver to
> sleep when it shouldn't.
> 
> This was introduced in 7acc619, but it wasn't triggered until 18a2689
> was merged to Linus' branch at point 6899608.
> 
> However, it seems most of the time this is used in a way that keeps the
> counter above 0, so nobody noticed. Also, it seems to depend on the
> configuration used.
> 
> I found the problem by loading isp1704_charger before any usb gadgets:
> http://article.gmane.org/gmane.linux.kernel/1226122
> 
> All versions after 2.6.39 are affected.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/usb/musb/musb_core.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)

Will you be including this in your next pull request for me to include
in my tree to go to Linus soon?

thanks,

greg k-h

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Greg KH]

On Thu, Dec 15, 2011 at 03:02:25PM -0800, Greg KH wrote:
> On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> > In musb_init_controller() there's a pm_runtime_put(), but there's no
> > pm_runtime_get(), which creates a mismatch that causes the driver to
> > sleep when it shouldn't.
> > 
> > This was introduced in 7acc619, but it wasn't triggered until 18a2689
> > was merged to Linus' branch at point 6899608.
> > 
> > However, it seems most of the time this is used in a way that keeps the
> > counter above 0, so nobody noticed. Also, it seems to depend on the
> > configuration used.
> > 
> > I found the problem by loading isp1704_charger before any usb gadgets:
> > http://article.gmane.org/gmane.linux.kernel/1226122
> > 
> > All versions after 2.6.39 are affected.
> > 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > ---
> >  drivers/usb/musb/musb_core.c |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> Will you be including this in your next pull request for me to include
> in my tree to go to Linus soon?

Doh, wrong Felipe, my apologies.

greg k-h

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Contreras]

On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
>> In musb_init_controller() there's a pm_runtime_put(), but there's no
>> pm_runtime_get(), which creates a mismatch that causes the driver to
>> sleep when it shouldn't.
>>
>> This was introduced in 7acc619, but it wasn't triggered until 18a2689
>> was merged to Linus' branch at point 6899608.
>
> you need to add the commit description (whatever was the mail's subject)
> here too. And you should put in Cc the author or those commits too,
> otherwise we can't poke into their brains to understand what they were
> thinking when they originally wrote those patches.

True, but code is code, and even if you don't know what he was
thinking, it's clear there's something wrong.

>> However, it seems most of the time this is used in a way that keeps the
>> counter above 0, so nobody noticed. Also, it seems to depend on the
>> configuration used.
>>
>> I found the problem by loading isp1704_charger before any usb gadgets:
>> http://article.gmane.org/gmane.linux.kernel/1226122
>>
>> All versions after 2.6.39 are affected.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>>  drivers/usb/musb/musb_core.c |    2 --
>>  1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> index b63ab15..920f04e 100644
>> --- a/drivers/usb/musb/musb_core.c
>> +++ b/drivers/usb/musb/musb_core.c
>> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
>>       if (status < 0)
>>               goto fail3;
>>
>> -     pm_runtime_put(musb->controller);
>
> To me the real fix would be add the missing pm_runtime_get_sync(). On
> probe() we're actually accessing MUSB's address space which needs it's
> clocks turned on. I guess it's only working now by chance, probably
> because glue layer calls pm_runtime_get_sync() to access it's own
> address space and that uses the same clocks.

Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
accessing the relevant address-space? From the runtime_pm
documentation it looks like only the probe function should deal with
this.

If "musb-hdrc" was truly accessing these registers, then I would get
the same failure because the clocks are turned off, but I don't...

Cheers.

-- 
Felipe Contreras

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]

On Fri, Dec 16, 2011 at 01:31:02AM +0200, Felipe Contreras wrote:
> On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> >> In musb_init_controller() there's a pm_runtime_put(), but there's no
> >> pm_runtime_get(), which creates a mismatch that causes the driver to
> >> sleep when it shouldn't.
> >>
> >> This was introduced in 7acc619, but it wasn't triggered until 18a2689
> >> was merged to Linus' branch at point 6899608.
> >
> > you need to add the commit description (whatever was the mail's subject)
> > here too. And you should put in Cc the author or those commits too,
> > otherwise we can't poke into their brains to understand what they were
> > thinking when they originally wrote those patches.
> 
> True, but code is code, and even if you don't know what he was
> thinking, it's clear there's something wrong.
> 
> >> However, it seems most of the time this is used in a way that keeps the
> >> counter above 0, so nobody noticed. Also, it seems to depend on the
> >> configuration used.
> >>
> >> I found the problem by loading isp1704_charger before any usb gadgets:
> >> http://article.gmane.org/gmane.linux.kernel/1226122
> >>
> >> All versions after 2.6.39 are affected.
> >>
> >> Cc: stable@vger.kernel.org
> >> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> >> ---
> >>  drivers/usb/musb/musb_core.c |    2 --
> >>  1 files changed, 0 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >> index b63ab15..920f04e 100644
> >> --- a/drivers/usb/musb/musb_core.c
> >> +++ b/drivers/usb/musb/musb_core.c
> >> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
> >>       if (status < 0)
> >>               goto fail3;
> >>
> >> -     pm_runtime_put(musb->controller);
> >
> > To me the real fix would be add the missing pm_runtime_get_sync(). On
> > probe() we're actually accessing MUSB's address space which needs it's
> > clocks turned on. I guess it's only working now by chance, probably
> > because glue layer calls pm_runtime_get_sync() to access it's own
> > address space and that uses the same clocks.
> 
> Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
> accessing the relevant address-space? From the runtime_pm
> documentation it looks like only the probe function should deal with
> this.
> 
> If "musb-hdrc" was truly accessing these registers, then I would get
> the same failure because the clocks are turned off, but I don't...

see musb_core_init(); You don't see any problems when accessing those
addresses because musb_platform_init() will fall into
omap2430_musb_init() which calls pm_runtime_get_sync(), and the same
clock actually enables both address spaces (musb-omap2430 and
musb-hdrc).

(now, this was all from memory, so it could be wrong ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Thu, Dec 15, 2011 at 03:11:03PM -0800, Greg KH wrote:
> On Thu, Dec 15, 2011 at 03:02:25PM -0800, Greg KH wrote:
> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> > > In musb_init_controller() there's a pm_runtime_put(), but there's no
> > > pm_runtime_get(), which creates a mismatch that causes the driver to
> > > sleep when it shouldn't.
> > > 
> > > This was introduced in 7acc619, but it wasn't triggered until 18a2689
> > > was merged to Linus' branch at point 6899608.
> > > 
> > > However, it seems most of the time this is used in a way that keeps the
> > > counter above 0, so nobody noticed. Also, it seems to depend on the
> > > configuration used.
> > > 
> > > I found the problem by loading isp1704_charger before any usb gadgets:
> > > http://article.gmane.org/gmane.linux.kernel/1226122
> > > 
> > > All versions after 2.6.39 are affected.
> > > 
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> > > ---
> > >  drivers/usb/musb/musb_core.c |    2 --
> > >  1 files changed, 0 insertions(+), 2 deletions(-)
> > 
> > Will you be including this in your next pull request for me to include
> > in my tree to go to Linus soon?
> 
> Doh, wrong Felipe, my apologies.

hehe. To answer the previous question: I want to hash a few things out
first, so it's likely that it won't make it for the next pull request to
Linus. Guess I'll have to send this either on 3.3 merge window or after
that and, of course, Cc stable (as Felipe C. did)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Contreras]

On Fri, Dec 16, 2011 at 1:50 AM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, Dec 16, 2011 at 01:31:02AM +0200, Felipe Contreras wrote:
>> On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
>> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
>> >> --- a/drivers/usb/musb/musb_core.c
>> >> +++ b/drivers/usb/musb/musb_core.c
>> >> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
>> >>       if (status < 0)
>> >>               goto fail3;
>> >>
>> >> -     pm_runtime_put(musb->controller);
>> >
>> > To me the real fix would be add the missing pm_runtime_get_sync(). On
>> > probe() we're actually accessing MUSB's address space which needs it's
>> > clocks turned on. I guess it's only working now by chance, probably
>> > because glue layer calls pm_runtime_get_sync() to access it's own
>> > address space and that uses the same clocks.
>>
>> Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
>> accessing the relevant address-space? From the runtime_pm
>> documentation it looks like only the probe function should deal with
>> this.
>>
>> If "musb-hdrc" was truly accessing these registers, then I would get
>> the same failure because the clocks are turned off, but I don't...
>
> see musb_core_init(); You don't see any problems when accessing those
> addresses because musb_platform_init() will fall into
> omap2430_musb_init() which calls pm_runtime_get_sync(), and the same
> clock actually enables both address spaces (musb-omap2430 and
> musb-hdrc).

That's true, but how would I go test this theory? Call
pm_runtime_put_sync() at the end of omap2430_musb_init()?

Also, I think most pm_runtime_disable() calls shouldn't be there...
That would tell PM to activate power for the device, which is not what
we want. The core drivers code will take care of truly disabling the
pm_runtime stuff _without_ activating the device.

Cheers.

-- 
Felipe Contreras

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Hi,

On Fri, Dec 16, 2011 at 03:13:13AM +0200, Felipe Contreras wrote:
> On Fri, Dec 16, 2011 at 1:50 AM, Felipe Balbi <balbi@ti.com> wrote:
> > On Fri, Dec 16, 2011 at 01:31:02AM +0200, Felipe Contreras wrote:
> >> On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
> >> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
> >> >> --- a/drivers/usb/musb/musb_core.c
> >> >> +++ b/drivers/usb/musb/musb_core.c
> >> >> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
> >> >>       if (status < 0)
> >> >>               goto fail3;
> >> >>
> >> >> -     pm_runtime_put(musb->controller);
> >> >
> >> > To me the real fix would be add the missing pm_runtime_get_sync(). On
> >> > probe() we're actually accessing MUSB's address space which needs it's
> >> > clocks turned on. I guess it's only working now by chance, probably
> >> > because glue layer calls pm_runtime_get_sync() to access it's own
> >> > address space and that uses the same clocks.
> >>
> >> Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
> >> accessing the relevant address-space? From the runtime_pm
> >> documentation it looks like only the probe function should deal with
> >> this.
> >>
> >> If "musb-hdrc" was truly accessing these registers, then I would get
> >> the same failure because the clocks are turned off, but I don't...
> >
> > see musb_core_init(); You don't see any problems when accessing those
> > addresses because musb_platform_init() will fall into
> > omap2430_musb_init() which calls pm_runtime_get_sync(), and the same
> > clock actually enables both address spaces (musb-omap2430 and
> > musb-hdrc).
> 
> That's true, but how would I go test this theory? Call
> pm_runtime_put_sync() at the end of omap2430_musb_init()?

sounds like a plan... Not sure if it will work always though. If I
remember correctly, pm_runtime_put_sync() will only be synchronous to
the current device, but will go up the parent tree asynchronously. Which
means that dev->parent will be see a scheduled runtime_put

> Also, I think most pm_runtime_disable() calls shouldn't be there...
> That would tell PM to activate power for the device, which is not what
> we want. The core drivers code will take care of truly disabling the
> pm_runtime stuff _without_ activating the device.

true, sounds correct.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Sergei Shtylyov]

Hello.

On 16-12-2011 2:42, Felipe Contreras wrote:

> In musb_init_controller() there's a pm_runtime_put(), but there's no
> pm_runtime_get(), which creates a mismatch that causes the driver to
> sleep when it shouldn't.

> This was introduced in 7acc619, but it wasn't triggered until 18a2689
> was merged to Linus' branch at point 6899608.

    Please also specify the summaries for the commits you're mentioning.

> However, it seems most of the time this is used in a way that keeps the
> counter above 0, so nobody noticed. Also, it seems to depend on the
> configuration used.

> I found the problem by loading isp1704_charger before any usb gadgets:
> http://article.gmane.org/gmane.linux.kernel/1226122

> All versions after 2.6.39 are affected.

> Cc: stable@vger.kernel.org
> Signed-off-by: Felipe Contreras<felipe.contreras@gmail.com>

WBR, Sergei

Re: [PATCH] usb: musb: fix pm_runtime mismatch

[Felipe Contreras]

On Fri, Dec 16, 2011 at 3:38 AM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, Dec 16, 2011 at 03:13:13AM +0200, Felipe Contreras wrote:
>> On Fri, Dec 16, 2011 at 1:50 AM, Felipe Balbi <balbi@ti.com> wrote:
>> > On Fri, Dec 16, 2011 at 01:31:02AM +0200, Felipe Contreras wrote:
>> >> On Fri, Dec 16, 2011 at 1:01 AM, Felipe Balbi <balbi@ti.com> wrote:
>> >> > On Fri, Dec 16, 2011 at 12:42:14AM +0200, Felipe Contreras wrote:
>> >> >> --- a/drivers/usb/musb/musb_core.c
>> >> >> +++ b/drivers/usb/musb/musb_core.c
>> >> >> @@ -2012,8 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
>> >> >>       if (status < 0)
>> >> >>               goto fail3;
>> >> >>
>> >> >> -     pm_runtime_put(musb->controller);
>> >> >
>> >> > To me the real fix would be add the missing pm_runtime_get_sync(). On
>> >> > probe() we're actually accessing MUSB's address space which needs it's
>> >> > clocks turned on. I guess it's only working now by chance, probably
>> >> > because glue layer calls pm_runtime_get_sync() to access it's own
>> >> > address space and that uses the same clocks.
>> >>
>> >> Are you sure it's "musb-hdrc", and not "musb-omap2430" the one
>> >> accessing the relevant address-space? From the runtime_pm
>> >> documentation it looks like only the probe function should deal with
>> >> this.
>> >>
>> >> If "musb-hdrc" was truly accessing these registers, then I would get
>> >> the same failure because the clocks are turned off, but I don't...
>> >
>> > see musb_core_init(); You don't see any problems when accessing those
>> > addresses because musb_platform_init() will fall into
>> > omap2430_musb_init() which calls pm_runtime_get_sync(), and the same
>> > clock actually enables both address spaces (musb-omap2430 and
>> > musb-hdrc).
>>
>> That's true, but how would I go test this theory? Call
>> pm_runtime_put_sync() at the end of omap2430_musb_init()?
>
> sounds like a plan... Not sure if it will work always though. If I
> remember correctly, pm_runtime_put_sync() will only be synchronous to
> the current device, but will go up the parent tree asynchronously. Which
> means that dev->parent will be see a scheduled runtime_put

I tested this. Nothing bad happens (until isp1704_charger actually
tries to do something, of course; the counters are messed up).

Cheers.

-- 
Felipe Contreras