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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2006-06-21 at 14:18 -0700, David Brownell wrote:
> On Tuesday 20 June 2006 7:40 pm, Linus Torvalds wrote:
> > 
> > It's not up to the driver to worry about request queues. 

Linus, You are contradicting yourself a bit I think... On one mailed,
you agreed that suspend() would happen in a "live" systems with no
quiescing of subsystems and now you say drivers shouldn't bother
blocking their request queues (or rather, stop processing them, but many
drivers handle their own requests queueing mecanism, if at all, against,
that term encompass both real "request queues" in the block driver
sense, packet queues in network drivers, ioctls, other callbakcs like
set_multicast_filter or whatever ramdom things that can be called by
your subsystem or as the result of userland actions).

> Maybe for block drivers.  But USB and network controller drivers
> are fundamentally about managing request queues, by collaborating
> with upper level drivers.

Yes and the upper level, in the case of ethernet drivers for example,
provides a very simple way of managing that queue. A single call blocks
it and properly synchronizes with the xmit callback. You still need to
be careful with ioctl, set_multicast/mac/... etc... though but you have
to anyway.

> Alternatively, you may be observing that just like block queues
> are managed by the upper layer code, so are USB queues managed
> by the usb_driver entities that freeze their own contributions,
> like network interfaces manage their network queues.  (Though in
> both cases the controller drivers must still wait for queues to
> empty before they are fully quiesced).

Block queues aren't entirely managed by upper layers neither

Ben.