IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Heiko Stübner]

Hi,

Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs
earlier) split the suspend/resume of the irqs into two parts.

The early-irqs get resumed during syscore_resume, while the rest get
resumed by the regular resume_device_irqs.

I may be blind, but where get the early-irqs resumed in the error
path of dpm_suspend_noirq?

When a suspend_noirq callback returns an error, dpm_resume_noirq gets called,
which only calls resume_device_irqs while the suspend_device_irqs call in
dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs
get resumed at all in this case.


Thanks
Heiko

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Laxman Dewangan]

On Wednesday 20 November 2013 02:50 PM, Heiko Stübner wrote:
> Hi,
>
> Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs
> earlier) split the suspend/resume of the irqs into two parts.
>
> The early-irqs get resumed during syscore_resume, while the rest get
> resumed by the regular resume_device_irqs.
>
> I may be blind, but where get the early-irqs resumed in the error
> path of dpm_suspend_noirq?
>
> When a suspend_noirq callback returns an error, dpm_resume_noirq gets called,
> which only calls resume_device_irqs while the suspend_device_irqs call in
> dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs
> get resumed at all in this case.
>
I also faced same issue in our suspend failure path and posted fix 
sometime ago as
https://lkml.org/lkml/2013/8/13/373

It is still under review.

You can try this patch if it resolve the issue.

Thanks,
Laxman

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Heiko Stübner]

Hi Laxman,

Am Mittwoch, 20. November 2013, 10:54:10 schrieb Laxman Dewangan:
> > I may be blind, but where get the early-irqs resumed in the error
> > path of dpm_suspend_noirq?
> > 
> > When a suspend_noirq callback returns an error, dpm_resume_noirq gets
> > called, which only calls resume_device_irqs while the
> > suspend_device_irqs call in dpm_suspend_noirq suspends all irqs. So it
> > does not seem that the early-irqs get resumed at all in this case.
> 
> I also faced same issue in our suspend failure path and posted fix
> sometime ago as
> https://lkml.org/lkml/2013/8/13/373
> 
> It is still under review.

>From the thread on lkml.org it looks like it got no reaction at all - maybe 
was just overlooked. So maybe it would be good to re-send it.

As it is not visible on lkml.org, did you also include stable@kernel.org, as 
the issue started in 2011?

> You can try this patch if it resolve the issue.

Your patch looks a lot more sophisticated than my current band-aid fix :-) by 
using the fact that irqs won't get resumed twice on their own.

So if you repost your patch you could add an

Acked-by: Heiko Stuebner <heiko@sntech.de>


Heiko

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Pavel Machek]

On Sat 2013-11-23 22:25:48, Heiko Stübner wrote:
> Hi Laxman,
> 
> Am Mittwoch, 20. November 2013, 10:54:10 schrieb Laxman Dewangan:
> > > I may be blind, but where get the early-irqs resumed in the error
> > > path of dpm_suspend_noirq?
> > > 
> > > When a suspend_noirq callback returns an error, dpm_resume_noirq gets
> > > called, which only calls resume_device_irqs while the
> > > suspend_device_irqs call in dpm_suspend_noirq suspends all irqs. So it
> > > does not seem that the early-irqs get resumed at all in this case.
> > 
> > I also faced same issue in our suspend failure path and posted fix
> > sometime ago as
> > https://lkml.org/lkml/2013/8/13/373
> > 
> > It is still under review.

If it helps, you can add my

Reviewed-by: Pavel Machek <pavel@ucw.cz>

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Pavel Machek]

Hi!

(Oops, it seems that this thread uses Rafael's old address, and that
it bounces, added address from maintainers to cc.)

								Pavel

On Sat 2013-11-23 22:25:48, Heiko Stübner wrote:
> Hi Laxman,
> 
> Am Mittwoch, 20. November 2013, 10:54:10 schrieb Laxman Dewangan:
> > > I may be blind, but where get the early-irqs resumed in the error
> > > path of dpm_suspend_noirq?
> > > 
> > > When a suspend_noirq callback returns an error, dpm_resume_noirq gets
> > > called, which only calls resume_device_irqs while the
> > > suspend_device_irqs call in dpm_suspend_noirq suspends all irqs. So it
> > > does not seem that the early-irqs get resumed at all in this case.
> > 
> > I also faced same issue in our suspend failure path and posted fix
> > sometime ago as
> > https://lkml.org/lkml/2013/8/13/373
> > 
> > It is still under review.
> 
> From the thread on lkml.org it looks like it got no reaction at all - maybe 
> was just overlooked. So maybe it would be good to re-send it.
> 
> As it is not visible on lkml.org, did you also include stable@kernel.org, as 
> the issue started in 2011?
> 
> > You can try this patch if it resolve the issue.
> 
> Your patch looks a lot more sophisticated than my current band-aid fix :-) by 
> using the fact that irqs won't get resumed twice on their own.
> 
> So if you repost your patch you could add an
> 
> Acked-by: Heiko Stuebner <heiko@sntech.de>
> 
> 
> Heiko

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Ian Campbell]

On Wed, 2013-11-20 at 15:24 +0530, Laxman Dewangan wrote:
> On Wednesday 20 November 2013 02:50 PM, Heiko Stübner wrote:
> > Hi,
> >
> > Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs
> > earlier) split the suspend/resume of the irqs into two parts.
> >
> > The early-irqs get resumed during syscore_resume, while the rest get
> > resumed by the regular resume_device_irqs.
> >
> > I may be blind, but where get the early-irqs resumed in the error
> > path of dpm_suspend_noirq?
> >
> > When a suspend_noirq callback returns an error, dpm_resume_noirq gets called,
> > which only calls resume_device_irqs while the suspend_device_irqs call in
> > dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs
> > get resumed at all in this case.
> >
> I also faced same issue in our suspend failure path and posted fix 
> sometime ago as
> https://lkml.org/lkml/2013/8/13/373
> 
> It is still under review.

IME zero comments since August is not "under review", it is "has slipped
through the cracks" ;-)

I would suggest you resend it.

Ian.

Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq

[Laxman Dewangan]

On Monday 25 November 2013 03:43 PM, Ian Campbell wrote:
> On Wed, 2013-11-20 at 15:24 +0530, Laxman Dewangan wrote:
>> On Wednesday 20 November 2013 02:50 PM, Heiko Stübner wrote:
>>> Hi,
>>>
>>> Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs
>>> earlier) split the suspend/resume of the irqs into two parts.
>>>
>>> The early-irqs get resumed during syscore_resume, while the rest get
>>> resumed by the regular resume_device_irqs.
>>>
>>> I may be blind, but where get the early-irqs resumed in the error
>>> path of dpm_suspend_noirq?
>>>
>>> When a suspend_noirq callback returns an error, dpm_resume_noirq gets called,
>>> which only calls resume_device_irqs while the suspend_device_irqs call in
>>> dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs
>>> get resumed at all in this case.
>>>
>> I also faced same issue in our suspend failure path and posted fix
>> sometime ago as
>> https://lkml.org/lkml/2013/8/13/373
>>
>> It is still under review.
> IME zero comments since August is not "under review", it is "has slipped
> through the cracks" ;-)
>
> I would suggest you resend it.
>

Thanks all of you for review/ack/validating it.
I resend it today. Hope at this time it will be on tree.

Howevere, I have not added stable on cc.