> 
> This is why I propose to make scsipi_channel_thaw public, this once can be
> called from your thread. But I don't think we should allow HBA drivers to
> bypass the freeze/thaw mechanism; this will break if we want to change the
> internals of scsipi.
> 

Can we come to some closure on this? I have a fairly large change to the FC
driver (which now quite nicely survives and retries LIPS after loop
re-evaluation where it didn't before) that I'd like to check in.

The current usage of scsipi_channel_thaw (which is public) does not call
scsipi_run_queue. The reason why this is not currently broken is that the
current usage of freeze/thaw is for resource shortage reasons, and some HBA
driver (ahc, e.g.) call scsipi_channel_thaw prior to calling scsipi_done
(which will call scspi_run_queue).

However, I'm talking about events which can unfreeze a queue with no commands
active. Therefore, I either have to call scspi_run_queue directly, or I have
to have some variant of scsipi_channel_thaw which makes sure that the queue
gets started again.

Suggestions?

-matt