On Fri, Jun 22, 2018 at 8:22 PM, Bart Van Assche <bart.vanassche@xxxxxxx> wrote: > On 06/21/18 22:35, Sreekanth Reddy wrote: >> >> No, lock_system_sleep() is not inserted in the interrupt context. we >> have inserted it in .resume() call back function just before issuing >> the IOC reset. > > > That's the wrong place to insert a lock_system_sleep() call. Please have a > look at drivers/scsi/scsi_transport_spi.c for an example of how to use that > function. > I am totally confused. In driver's .resume() callback function, driver is doing IOC reset operation. And as per your suggestion we tried using scsi_internal_device_block_nowait() to block the all the devices attached to the HBA before going for IOC reset operation. During system resume time as drives will be in quiesce state and calling scsi_internal_device_block_nowait() return with error status -22. So you suggested us to try using lock_system_sleep() API before calling scsi_internal_device_block_nowait(), so that we don't get -22 return status when we call scsi_internal_device_block_nowait() API during resume time. We tried the same and we see system get hang during hibernation. Please correct me if I am wrong or if I have wrongly understood your suggestions. I feel that the fix which have posted is the better fix then using scsi_internal_device_block_nowait()/scsi_internal_device_unblock_nowait() APIs. Thanks, Sreekanth > Thanks, > > Bart.
