Re: [PATCH 2/2] Fix console handling during suspend/resume

[Adam Belay <ambx1@neo.rr.com>]

On Fri, Jun 23, 2006 at 12:23:53PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 23 Jun 2006, David Brownell wrote:
> > 
> > Seriously, suspend() tends to be less of a problem than resume().  Which
> > is why I'm lukewarm to notions of refactoring suspend().
> 
> Now, I obviously agree, I just don't see any good way to refactor resume 
> at all.
> 
> So I think we should attack the problems that we _can_ attack.
> 
> Btw, I disagree violently with the standpoint that you and Pavel have had 
> that we currently just do enough in "suspend()" to make STR work, and that 
> gets STD working automatically.
> 
> Several suspend() functions I've seen (networking in particular) do a 
> _hell_ of a lot more than they need for STR, exactly because they try to 
> protect against problems that happen with STD, but _not_ STR.
> 
> Network devices tend to do things like "unregister from the network stack" 
> etc, all of which should be totally unnecessary for STR. It's all there 
> really for _disk_ suspend, to make things quiet.
> 
> So the whole argument that "suspend()" is the minimal functionality is 
> just totally bogus. Its' simply not _true_. The current suspend() 
> functions do lots of things that have nothing to do with actual device 
> suspend, exactly because the current setup forces them to do so, not 
> because they would actually _need_ to do so for STR.
> 
> 			Linus

As far as I understand, most of them call netif_device_detach(), which just
set's a flag bit that indicates the hardware isn't available for a moment,
but this isn't the same as unregistering from the netdev stack.

In my opinion, the point here is that the suspend functions are trying to
prevent access to hardware.  In the suspend-to-ram case the device might be
uninitialized or powered off.  As a result touching the hardware may lead to
driver errors, master aborts, lost data, or other problems.  Similarly, the
goal during suspend-to-disk memory snapshotting is just to quiet down the
drivers by stopping DMA, interrupts, and other hardware access so it's easier
to create a functional memory snapshot, even if it isn't entirely atomic.

In either case, it's important to a.) tell the driver to stop touching it's
hardware for a moment, b.) make sure the hardware itself is quiet enough and
c.) optionally push out any queues or buffers of data waiting to hit the
device.  Of course, there are also a lot of activities that are not shared
between each suspend scenario.  For example, when suspending devices before
entering S3 (or whatever the platform calls suspend-to-ram) it's important,
in addition to the above, to save dynamic device context, enter the correct
device power state, and enable wakeup capabilities if needed.  In contrast,
when preparing for a memory snapshot, it's important to save dynamic device
context but device power must be maintained.  As a third example, before
entering S5 it might be best to transition devices to lower power states
and enable wakeup features, but there is no need to save dynamic context.

Now I'm not arguing that the current suspend model is correct, in fact I think
it's in need of some major restructuring.  Nor am I arguing that this all must
happen in a single unified suspend callback.  I just want to suggest that in
any suspend case, one of the most important objectives is to quiesce the
driver and hardware.  As a result, every type of suspend() operation has at
least some similar requirements.

Thanks,
Adam