On 03/12/14 01:11, Rafael J. Wysocki wrote:

> Second, what if the parent sets its irq_safe after the child does?

Then the behavior becomes the same as it is currently.

But isn't the probe of the parent always ran before the child? And the
only sane place (?) to set irq_safe is in probe, after
pm_runtime_enable. If so, it should never happen in practice that the
parent's irq_safe is called after the child's.

>> If the thing I am doing somehow fundamentally flawed, I 	apologize. 
>> However, this was an RFC patch after all and the problem I am trying to 
>> solve is real.
> 
> Well, the whole irq_safe concept if somewhat rough and fragile (for example,
> it doesn't play well with bus type callbacks that may sleep) and I'm not

I don't know enough of the PM to understand what you mean with above,
but isn't it a bug to set a device irq-safe if it may need sleeping
callbacks? Or do you mean that the device driver may not know if such
sleeping callbacks happen or not?

> sure if making it more fragile is a good idea.

Is there something we can do to fix it? Conceptually I don't see any
issues with it, but I'm probably only looking at it from the platform
device point of view.

 Tomi