[PATCH v2] ufs: core: Avoid IRQ thread wakeup during active UIC command

[Peter Wang (王信友)]

On Tue, 2026-03-17 at 18:11 +0100, Marek Szyprowski wrote:
> This patch landed in linux-next as commit 6475cfb81fc4 ("scsi: ufs: 
> core: Avoid IRQ thread wakeup during active UIC command"). In my
> tests I 
> found that it causes the following regression on QCom RB5 board 
> (arch/arm64/boot/dts/qcom/qrb5165-rb5.dts):

Hi Marek,

If this issue can always be reproduced with this patch?
I have doubts because, in your log, it seems to be ISR trying
to acquire the spinlock (shost->host_lock), but cannot obtain
it in time, causing a timeout.

ufshcd-qcom 1d84000.ufshc: uic cmd 0x1 with arg3 0x0 completion timeout
ufshcd-qcom 1d84000.ufshc: dme-get: sttr-id 0x41 failed 0 retries no
locks held by swapper/0/0.
ufshcd-qcom 1d84000.ufshc: ufs_wcom_check_hibern8: unable to get
TX_FSM_STATE, err -110 stack backtrace:
ufshcd-qcom 1d84000.ufshc: No active UIC command. Maybe a timeout
occurred?
ufshcd-qcom 1d84000.ufshc: ufshcd_threaded_intr: Unhadled interrupt
0x00000000 (0x00000400, 0x00000400)

Regardless of whether it runs in IRQ or thread IRQ context, the
outcome is the same (host_lock cannot be acquired in time).
So, could you check why this spinlock cannot be acquired first?
Additionally, ufs_wcom_check_hibern8 does not appear in the
current code base, so there might be some other unknown code 
that has already acquired host_lock in your code base?

Thanks
Peter