Re: [PATCH/RFC 1/2] simple SPI framework

[David Brownell]

> > >+ * 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/