scsi: sd: Revert "Rework asynchronous resume support"

scsi: sd: Revert "Rework asynchronous resume support"

Although commit 88f1669019bd ("scsi: sd: Rework asynchronous resume support")
eliminates a delay for some ATA disks after resume, it causes resume of ATA
disks to fail on other setups. See also:

 * "Resume process hangs for 5-6 seconds starting sometime in 5.16"
   (https://bugzilla.kernel.org/show_bug.cgi?id=215880).

 * Geert's regression report
   (https://lore.kernel.org/linux-scsi/alpine.DEB.2.22.394.2207191125130.1006766@ramsan.of.borg/).

This is what I understand about this issue:

 * During resume, ata_port_pm_resume() starts the SCSI error handler.  This
   changes the SCSI host state into SHOST_RECOVERY and causes
   scsi_queue_rq() to return BLK_STS_RESOURCE.

 * sd_resume() calls sd_start_stop_device() for ATA devices. That function
   in turn calls sd_submit_start() which tries to submit a START STOP UNIT
   command. That command can only be submitted after the SCSI error handler
   has changed the SCSI host state back to SHOST_RUNNING.

 * The SCSI error handler runs on its own thread and calls
   schedule_work(&(ap->scsi_rescan_task)). That causes
   ata_scsi_dev_rescan() to be called from the context of a kernel
   workqueue. That call hangs in blk_mq_get_tag(). I'm not sure why - maybe
   because all available tags have been allocated by sd_submit_start()
   calls (this is a guess).

Link: https://lore.kernel.org/r/20220816172638.538734-1-bvanassche@acm.org
Fixes: 88f1669019bd ("scsi: sd: Rework asynchronous resume support")
Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: gzhqyz@gmail.com
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: gzhqyz@gmail.com
Reported-and-tested-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: John Garry <john.garry@huawei.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>