linux.git/drivers/scsi/libsas, branch v5.17

scsi: libsas: Keep host active while processing events

2021-12-23T04:38:31+00:00

Processing events such as PORTE_BROADCAST_RCVD may cause dependency issues
for runtime power management support.  Such a problem would be that
handling a PORTE_BROADCAST_RCVD event requires that the host is resumed to
send SMP commands. However, in resuming the host, the phyup events
generated from re-enabling the phys are processed in the same workqueue as
the original PORTE_BROADCAST_RCVD event. As such, the host will never
finish resuming (as it waits for the phyup event processing), and then the
PORTE_BROADCAST_RCVD event can't be processed as the SMP commands are
blocked, and so we have a deadlock.  Solve this problem by ensuring that
libsas keeps the host active until completely finished phy or port events,
such as PORTE_BYTES_DMAED. As such, we don't have to worry about resuming
the host for processing individual SMP commands in this example.

Link: https://lore.kernel.org/r/1639999298-244569-15-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Defer works of new phys during suspend

2021-12-23T04:38:30+00:00

During the processing of event PORT_BYTES_DMAED, the driver queues work
DISCE_DISCOVER_DOMAIN and then flushes workqueue ha->disco_q.  If a new
phyup event occurs during resuming the controller, the work
PORTE_BYTES_DMAED of new phy occurs before suspended phy's. The work
DISCE_DISCOVER_DOMAIN of new phy requires an active SAS controller (it
needs to resume SAS controller by function scsi_sysfs_add_sdev() and some
other functions such as function add_device_link()). However, the
activation of the SAS controller requires completion of work
PORTE_BYTES_DMAED of suspended phys while it is blocked by new phy's work
on ha->event_q. So there is a deadlock and it is released only after resume
timeout.

To solve the issue, defer works of new phys during suspend and queue those
defer works after SAS controller becomes active.

Link: https://lore.kernel.org/r/1639999298-244569-13-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Refactor sas_queue_deferred_work()

2021-12-23T04:38:30+00:00

In the second part of function __sas_drain_work(), deferred work is queued.
This functionality is required other places so factor it out into the
function sas_queue_deferred_work().

Link: https://lore.kernel.org/r/1639999298-244569-12-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Add flag SAS_HA_RESUMING

2021-12-23T04:38:30+00:00

Add a flag SAS_HA_RESUMING and use it to indicate the state of resuming the
host controller.

Link: https://lore.kernel.org/r/1639999298-244569-11-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Resume host while sending SMP I/Os

2021-12-23T04:38:30+00:00

When sending SMP I/Os to the host we need to ensure that the host is not
suspended and can process the commands. This is a better approach than
replying on the host to resume itself to handle such commands. Use
pm_runtime_get_sync() and pm_runtime_put_sync() calls for the host when
executing SMP I/Os.

Link: https://lore.kernel.org/r/1639999298-244569-10-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Insert PORTE_BROADCAST_RCVD event for resuming host

2021-12-23T04:38:30+00:00

If a new disk is inserted through an expander when the host was suspended,
it will not necessarily be detected as the topology is not re-scanned
during resume.  To detect possible changes in topology during suspension,
insert a PORTE_BROADCAST_RCVD event per port when resuming to trigger a
revalidation.

Link: https://lore.kernel.org/r/1639999298-244569-8-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Add spin_lock/unlock() to protect asd_sas_port->phy_list

2021-12-23T04:38:29+00:00

Most places that use asd_sas_port->phy_list in libsas are protected by
spinlock asd_sas_port->phy_list_lock. However, there are still a few places
which miss the lock. Add it in those places.

Link: https://lore.kernel.org/r/1639999298-244569-5-git-send-email-chenxiang66@hisilicon.com
Reviewed-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Don't always drain event workqueue for HA resume

2021-12-23T04:38:29+00:00

For the hisi_sas driver, if a directly attached disk is removed during
suspend, a hang will occur in the resume process:

The background is that in commit 16fd4a7c5917 ("scsi: hisi_sas: Add device
link between SCSI devices and hisi_hba"), it is ensured that the HBA device
cannot be runtime suspended when any SCSI device associated is active.

Other drivers which use libsas don't worry about this as none support
runtime suspend.

The mentioned hang occurs when an disk is removed during suspend. In the
removal process - from PHYE_RESUME_TIMEOUT event processing - we call into
scsi_remove_device(), which is being processed in the HA event workqueue.
Here we wait for all suppliers of the SCSI device to resume, which includes
the HBA device (from the above commit). However the HBA device cannot
resume, as it is waiting for the PHYE_RESUME_TIMEOUT to be processed (from
calling sas_resume_ha() -> sas_drain_work()). This is the deadlock.

There does not appear to be any need for the sas_drain_work() to be called
at all in sas_resume_ha() as it is not syncing against anything, so allow
LLDDs to avoid this by providing a variant of sas_resume_ha() which does
"sync", i.e. doesn't drain the event workqueue.

Link: https://lore.kernel.org/r/1639999298-244569-2-git-send-email-chenxiang66@hisilicon.com
Signed-off-by: John Garry 
Signed-off-by: Xiang Chen 
Signed-off-by: Martin K. Petersen

scsi: libsas: Decode SAM status and host byte codes

2021-12-17T03:59:58+00:00

Value 0 is used for SAM status and libsas exec_status bytes codes in
sas_end_task() - use defined macros instead. In addition, change to proper
enum types.

Also replace SAM_STAT_CHECK_CONDITION with SAS_SAM_STAT_CHECK_CONDITION,
the former being a proper member of enum exec_status.

Link: https://lore.kernel.org/r/1639579061-179473-9-git-send-email-john.garry@huawei.com
Signed-off-by: John Garry 
Signed-off-by: Martin K. Petersen

scsi: Remove superfluous #include directives

2021-11-30T04:02:15+00:00

Remove this include directive from code that does not use any functionality
from kernel/async.c.

Link: https://lore.kernel.org/r/20211129194609.3466071-13-bvanassche@acm.org
Reviewed-by: Daejun Park 
Signed-off-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen