Re: [PATCH v1] scsi: ufs: core: Hold a clock reference across the probe

[Peter Wang]

On Wed, 2026-09-09 at 17:10 +0800, Naomi Chu wrote:
> Clock gating becomes possible as soon as ufshcd_init_clk_gating() has
> run, and from that point on the probe keeps accessing host registers
> without ever taking a clock reference. This has been safe only
> because
> of the state check in __ufshcd_release(): gate_work is not queued
> unless hba->ufshcd_state is UFSHCD_STATE_OPERATIONAL, and the
> promotion
> to that state used to happen after the last register access of the
> probe, at the end of ufshcd_probe_hba().
> 
> That is fragile: it only works while the promotion happens after the
> register accesses. Commit a390e6677f41 ("scsi: ufs: core: Expand the
> ufshcd_device_init(hba, true) call") changed that ordering by moving
> the promotion into ufshcd_init(), which schedules ufshcd_async_scan()
> afterwards. ufshcd_probe_hba() therefore now runs with the state
> already promoted, and it accesses host registers without holding a
> clock reference:
> 
>  - on hosts with UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH it calls
>    ufshcd_hba_stop() and ufshcd_hba_enable() before
>    ufshcd_device_init() sets the state back to UFSHCD_STATE_RESET,
> and
>    both read REG_CONTROLLER_ENABLE, so gated clocks stall there
> instead
>    of just losing a write.
>  - it ends with an ufshcd_configure_auto_hibern8() write, which its
>    other callers do take a clock reference for.
> 
> Take a clock reference as soon as clock gating has been initialised
> and
> keep it until the probe is over. It then does not matter who drops a
> clock reference while the probe is running, and the register accesses
> of the probe no longer depend on hba->ufshcd_state. The reference is
> dropped by ufshcd_async_scan() once the scan has finished, or by the
> new out_release label if the probe fails after it was taken.
> 
> Fixes: a390e6677f41 ("scsi: ufs: core: Expand the
> ufshcd_device_init(hba, true) call")
> Signed-off-by: Naomi Chu <naomi.chu@xxxxxxxxxxxx>
> ---

Reviewed-by: Peter Wang <peter.wang@xxxxxxxxxxxx>