> > >+ * NOTE: the suspend() method for an spi_master controller driver
> > >+ * should verify that all its child devices are marked as suspended;
> > >+ * suspend requests delivered through sysfs power/state files don't
> > >+ * enforce such constraints.
>
> But we should, right? It seems like a child device should never be in a
> higher suspend state than its parents. The rule doesn't have to hold with
> driver-initiated runtime power management, but when the user requests a
> suspend via power/state, it's reasonable to assume every child should
> be suspended first.
Adam ... that's a glitch in the (lack of) Runtime PM support. I tend
to agree that the kernel should enforce that, but it's an issue that
EVERY device has right now, not just SPI devices. (And it only affects
users of /sys/devices/.../power/state files, not /sys/power/state, so
the impact is low.)
Plus as has recently been brought up on the PM list, I suspect that the
"pm core" should just ignore all notions of state and leave that up to
driver code that's actually in a position to do something sane with the
relevant sorts of hardare and/or driver state.
That is, the PM core basically can't know ANYTHING real about how the
hardware acts. Heck, it doesn't even understand that a PCI device in
state PCI_D2 can go to PCI_D3hot without needing to be resumed first.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
