On śro, 2014-09-24 at 19:53 +0200, Pavel Machek wrote:
> On Wed 2014-09-24 15:50:08, Krzysztof Kozlowski wrote:
> > Add a simple getter pm_runtime_is_irq_safe() for quering whether runtime
> > PM IRQ safe was set or not.
> >
> > Various bus drivers implementing runtime PM may use choose to suspend
> > differently based on IRQ safeness status of child driver (e.g. do not
> > unprepare the clock if IRQ safe is not set).
> >
> > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx>
> > Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
>
> Are you sure this is good interface?
>
> "Tell me if another function works this or that way".
>
> That's certainly not traditional interface, and it seems dangerous to
> me. Callbacks now have different semantic requirements based on value
> of some flag...
Yes... but to me that semantic change looks similar to the PM runtime
code which behaves differently when the flag is set. Some PM runtime
functions might sleep or might not... depending on the flag.
> Would it be possible to have two sets of callbacks, one irq safe and
> one not?
That would require changing the callbacks during probe of each driver.
It is possible - I'm fine with that. However we still would need some
kind of interface for selecting the callbacks according to irq safe
status - something like pm_runtime_is_irq_safe():
static int amba_probe(struct device *dev)
{
...
if (pm_runtime_is_irq_safe())
dev->driver->pm = &amba_pm_irq_safe;
else
dev->driver->pm = &amba_pm;
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
