suggestion on resumption

suggestion on resumption

[Oliver Neukum]

Hi,

using the USB autosuspend framework I've often faced characteristic
problems coding resume() methods. This has led me to an idea. Resume()
would be much easier to code if I knew about the reason of resumption,
especially about the code path resume() is called in. I wonder whether
we could introduce a message argument to resume and give it a few
bits from the caller.

	Regards
		Oliver

Re: suggestion on resumption

[Rafael J. Wysocki]

On Thursday 26 November 2009, Oliver Neukum wrote:
> Hi,
> 
> using the USB autosuspend framework I've often faced characteristic
> problems coding resume() methods. This has led me to an idea. Resume()
> would be much easier to code if I knew about the reason of resumption,
> especially about the code path resume() is called in. I wonder whether
> we could introduce a message argument to resume and give it a few
> bits from the caller.

Each of the callbacks in struct dev_pm_ops is executed in exactly one context,
so for each of them it is known why it was called.

Thanks,
Rafael

Re: suggestion on resumption

[Oliver Neukum]

Am Freitag, 27. November 2009 01:47:44 schrieb Rafael J. Wysocki:
> On Thursday 26 November 2009, Oliver Neukum wrote:
> > Hi,
> >
> > using the USB autosuspend framework I've often faced characteristic
> > problems coding resume() methods. This has led me to an idea. Resume()
> > would be much easier to code if I knew about the reason of resumption,
> > especially about the code path resume() is called in. I wonder whether
> > we could introduce a message argument to resume and give it a few
> > bits from the caller.
> 
> Each of the callbacks in struct dev_pm_ops is executed in exactly one
>  context, so for each of them it is known why it was called.

But the resume method in the driver doesn't learn. It is an extrem hassle
not to know whether you are called synchronously (ie from open which
already holds a lock) or asynchronously (which means you need to guard
against open)

	Regards
		Oliver

Re: suggestion on resumption

[Alan Stern]

On Fri, 27 Nov 2009, Oliver Neukum wrote:

> Am Freitag, 27. November 2009 01:47:44 schrieb Rafael J. Wysocki:
> > On Thursday 26 November 2009, Oliver Neukum wrote:
> > > Hi,
> > >
> > > using the USB autosuspend framework I've often faced characteristic
> > > problems coding resume() methods. This has led me to an idea. Resume()
> > > would be much easier to code if I knew about the reason of resumption,
> > > especially about the code path resume() is called in. I wonder whether
> > > we could introduce a message argument to resume and give it a few
> > > bits from the caller.
> > 
> > Each of the callbacks in struct dev_pm_ops is executed in exactly one
> >  context, so for each of them it is known why it was called.
> 
> But the resume method in the driver doesn't learn. It is an extrem hassle
> not to know whether you are called synchronously (ie from open which
> already holds a lock) or asynchronously (which means you need to guard
> against open)

With the new Runtime PM framework, there isn't always a one-to-one 
correspondence between resume requests and method callbacks.  So the 
"reason" for a callback isn't always well defined.  And even if it 
were, the callback might happen in a different thread from the request.

The way to guard against open from an asynchronous context is to 
approach the problem the other way around: Guard against async contexts 
while open is running.  In other words, have open do an autoresume.

Exactly what situation are you concerned about?

Alan Stern

Re: suggestion on resumption

[Oliver Neukum]

Am Freitag, 27. November 2009 18:43:12 schrieb Alan Stern:
> > But the resume method in the driver doesn't learn. It is an extrem hassle
> > not to know whether you are called synchronously (ie from open which
> > already holds a lock) or asynchronously (which means you need to guard
> > against open)
> 
> With the new Runtime PM framework, there isn't always a one-to-one 
> correspondence between resume requests and method callbacks.  So the 
> "reason" for a callback isn't always well defined.  And even if it 
> were, the callback might happen in a different thread from the request.

That is exactly what I need to know.

> The way to guard against open from an asynchronous context is to 
> approach the problem the other way around: Guard against async contexts 
> while open is running.  In other words, have open do an autoresume.

That is the problem locking requirements are different when I do that
and I don't know what's the case.

	Regards
		Oliver

Re: suggestion on resumption

[Alan Stern]

On Fri, 27 Nov 2009, Oliver Neukum wrote:

> Am Freitag, 27. November 2009 18:43:12 schrieb Alan Stern:
> > > But the resume method in the driver doesn't learn. It is an extrem hassle
> > > not to know whether you are called synchronously (ie from open which
> > > already holds a lock) or asynchronously (which means you need to guard
> > > against open)
> > 
> > With the new Runtime PM framework, there isn't always a one-to-one 
> > correspondence between resume requests and method callbacks.  So the 
> > "reason" for a callback isn't always well defined.  And even if it 
> > were, the callback might happen in a different thread from the request.
> 
> That is exactly what I need to know.
> 
> > The way to guard against open from an asynchronous context is to 
> > approach the problem the other way around: Guard against async contexts 
> > while open is running.  In other words, have open do an autoresume.
> 
> That is the problem locking requirements are different when I do that
> and I don't know what's the case.

What are the details?

Alan Stern