kernel/drivers/scsi/libsas/sas_event.c, branch linux-6.9.y

scsi: libsas: Use bool for queue_work() return code

2022-02-28T02:48:30Z

Function queue_work() returns a bool, so use a bool to hold this value for the return code from callers, which should make the code a tiny bit more clear. Also take this opportunity to condense the code of the those callers, such as sas_queue_work(), as suggested by Damien. Link: https://lore.kernel.org/r/1645786656-221630-3-git-send-email-john.garry@huawei.com Reviewed-by: Damien Le Moal Signed-off-by: John Garry Signed-off-by: Martin K. Petersen

scsi: libsas: Make sas_notify_{phy,port}_event() return void

2022-02-28T02:48:29Z

Nobody checks the return codes, so make them return void. Indeed, if the LLDD cannot send an event, nothing much can be done in the LLDD about it. Also remove prototype for sas_notify_phy_event() in sas_internal.h, which should not be there. Link: https://lore.kernel.org/r/1645786656-221630-2-git-send-email-john.garry@huawei.com Reviewed-by: Xiang Chen Reviewed-by: Damien Le Moal Signed-off-by: John Garry Signed-off-by: Martin K. Petersen

scsi: libsas: Keep host active while processing events

2021-12-23T04:38:31Z

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:30Z

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:30Z

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 spin_lock/unlock() to protect asd_sas_port->phy_list

2021-12-23T04:38:29Z

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: Remove temporarily-added _gfp() API variants

2021-01-23T02:31:10Z

These variants were added for bisectability. Remove them, as all call sites have now been convertd to use the original API. Link: https://lore.kernel.org/r/20210118100955.1761652-20-a.darwish@linutronix.de Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen

scsi: libsas: Switch back to original event notifiers API

2021-01-23T02:31:09Z

libsas event notifiers required an extension where gfp_t flags must be explicitly passed. For bisectability, a temporary _gfp() variant of such functions were added. All call sites then got converted use the _gfp() variants and explicitly pass GFP context. Having no callers left, the original libsas notifiers were then modified to accept gfp_t flags by default. Switch back to the original event notifiers API, while still passing GFP context. The _gfp() notifier variants will be removed afterwards. Link: https://lore.kernel.org/r/20210118100955.1761652-17-a.darwish@linutronix.de Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen

scsi: libsas: Add gfp_t flags parameter to event notifications

2021-01-23T02:31:09Z

All call-sites of below libsas APIs: - sas_alloc_event() - sas_notify_port_event() - sas_notify_phy_event() have been converted to use the _gfp()-suffixed version. Modify the original APIs above to take a gfp_t flags parameter by default. For bisectability, call-sites will be modified again to use the original libsas APIs (while passing gfp_t). The temporary _gfp()-suffixed versions can then be removed. Link: https://lore.kernel.org/r/20210118100955.1761652-13-a.darwish@linutronix.de Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen

scsi: libsas: Pass gfp_t flags to event notifiers

2021-01-23T02:31:08Z

Use the new libsas event notifiers API, which requires callers to explicitly pass the gfp_t memory allocation flags. Context analysis: - sas_enable_revalidation(): process, acquires mutex - sas_resume_ha(): process, calls wait_event_timeout() Link: https://lore.kernel.org/r/20210118100955.1761652-9-a.darwish@linutronix.de Cc: Jason Yan Reviewed-by: John Garry Signed-off-by: Ahmed S. Darwish Signed-off-by: Martin K. Petersen