Re: [PATCH] ufs: core: Fix a deadlock in the frequency scaling code

[Bart Van Assche <bvanassche@acm.org>]

On 12/9/25 3:33 AM, Manivannan Sadhasivam wrote:
> Thanks for the quirk fix. While it seems to have fixed the boot hang, I'm
> quite skeptical about the fix. What is the guarantee that another device
> management command won't be submitted before blk_mq_unquiesce_tagset() in the
> future? IOW, the developer would have no idea that doing such will result in a
> deadlock as nothing in the UFS code makes it clear, like using the same lock and
> such.
I think that the recent changes can be considered as a bug fix. With 
previous kernel versions, only SCSI commands were paused during clock
frequency transitions but device management commands not. With the
approach that landed in Linus' master branch, device management commands
are also paused during clock frequency transitions. Device management
commands should also be paused because these also use the communication
link between host controller and UFS device.

Regarding debugging potential future deadlocks caused by submitting a
device management command while the tag set is quiesced, a call trace
is sufficient to discover the root cause (echo w > /proc/sysrq-trigger).

Regarding future changes in ufshcd_clock_scaling_unprepare(), I think
there are two cases: changes made by developers who have access to a
test setup that supports frequency scaling and changes made by
developers who don't have access to a test setup that supports frequency
scaling. Has it already been considered to insert calls to
ufshcd_clock_scaling_prepare() and ufshcd_clock_scaling_unprepare() near
the end of ufshcd_async_scan() to make sure that this code gets executed
on test setups that do not support frequency scaling?

Thanks,

Bart.