> > All calls are made with interrupts enabled, except for the > > SUSPEND_POWER_DOWN level. > > This is a slight problem for USB. We need to switch on interupts > to send a message to the device.

For example, to enable remote wakeup (whenever we start tosupport that). I understand that a lot of USB hardware doesnot work reliably if that's enabled much before a USB suspend.If only SUSPEND_POWER_DOWN notification was delivered, that'dhave to be enabled at that point.

>>Why would you allocate memory on a resume transition?

One example comes to mind. There are systems that, ratherthan supporting a "suspend to reduced power", are actuallyset up so they "suspend to no power". Or in short, theypower off in cases when other systems don't ... saving evenmore power. (I think that is the difference between D3hotand D3cold, or somesuch, but there are so many differentnames for the various states and contexts that I've beenknown to get them wrong.)

In that case, a "resume" needs to be able to completelyre-initialize the hardware. As a rule, that's going towant to be able to allocate memory.

... though FWIW I missed seeing anything that showed howthose API summaries would place constraints on allocatingmemory, so I didn't assume there could be any.

What did seem to be missing was anything saying whetherthose device methods would be called in_interrupt() orwhether instead they could sleep. I'd hope all of themwould be specified to allow blocking as needed, like theircurrent analogues in PCI and USB.

Also, there was some mention not that long ago aboutdesirability of some kind of device abort() call. Thatwould differ from the current remove() call because anabort() would pass the explicit knowledge that hardwarewas gone ... unplugged before driver shutdown, for oneexample. That could also be achieved using some kindof mode parameter to remove() -- perhaps three values,saying whether the hardware was present, removed, orin some indeterminate state.