Re: [RFC] Fix Device Power Management States

[Pavel Machek]

Hi!

> > >   This is implemented by iterating through the list of struct classes,
> > >   then through each of their struct class_device's. The class_device is
> > >   the only argument to those functions.
> >
> > Hrm... I don't agree, that iteration should be done in bus ordering too.
> >
> > For example, if you stop operation of a USB host controller, you have to
> > do that after you have stopped operation of child devices. Same goes
> > with the ATA disk vs. controller. The ordering requirements for stopping
> > operations are the same as for PM
> 
> It's easy enough to change which order things get stopped/started in. What
> matters more is the conceptual shift in responsibility for who
> stops/starts the devices, or rather their interfaces.

Can you explain why this class-based quiescing is good idea? It seems
to me that "quiesce this tree" is pretty much same as "suspend this
tree", and can be handled in the same way.

Nigel wanted to do class-based quiescing, but if we make quiescing
fast enough, it should be okay to do whole tree, always. (And I
believe quiescing *can* be fast enough).

> The driver core calls it in device_power_down() (as was in the patch ;),
> in physical topological order. The ordering of the calls is up the power
> management core, but it just wouldn't make sense to power down a device
> that wasn't stopped. Would be easy enough to add a check for it..

BUG_ON() would be welcome, otherwise someone will get it wrong.
								Pavel

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/