Re: [PATCH 2/2] ufs: host: scale ICE clock

From: Abhinaba Rakshit

Date: Wed Nov 12 2025 - 01:25:44 EST


On Thu, Oct 02, 2025 at 12:23:37AM +0000, Bryan O'Donoghue wrote:
> On 01/10/2025 12:38, Abhinaba Rakshit wrote:
> > Scale ICE clock from ufs controller.
>
> UFS

Sure, will take car of it in patchset v2.

>
> >
> > Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@xxxxxxxxxxxxxxxx>
> > ---
> > drivers/ufs/host/ufs-qcom.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> > index 3e83dc51d53857d5a855df4e4dfa837747559dad..2964b95a4423e887c0414ed9399cc02d37b5229a 100644
> > --- a/drivers/ufs/host/ufs-qcom.c
> > +++ b/drivers/ufs/host/ufs-qcom.c
> > @@ -305,6 +305,13 @@ static int ufs_qcom_ice_prepare_key(struct blk_crypto_profile *profile,
> > return qcom_ice_prepare_key(host->ice, lt_key, lt_key_size, eph_key);
> > }
> >
> > +static int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, bool scale_up)
> > +{
> > + if (host->hba->caps & UFSHCD_CAP_CRYPTO)
> > + return qcom_ice_scale_clk(host->ice, scale_up);
> > + return 0;
> > +}
> > +
> > static const struct blk_crypto_ll_ops ufs_qcom_crypto_ops = {
> > .keyslot_program = ufs_qcom_ice_keyslot_program,
> > .keyslot_evict = ufs_qcom_ice_keyslot_evict,
> > @@ -339,6 +346,11 @@ static void ufs_qcom_config_ice_allocator(struct ufs_qcom_host *host)
> > {
> > }
> >
> > +static inline int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, bool scale_up)
> > +{
> > + return 0;
> > +}
> > +
> > #endif
> >
> > static void ufs_qcom_disable_lane_clks(struct ufs_qcom_host *host)
> > @@ -1636,6 +1648,8 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba, bool scale_up,
> > else
> > err = ufs_qcom_clk_scale_down_post_change(hba, target_freq);
> >
> > + if (!err)
> > + err = ufs_qcom_ice_scale_clk(host, scale_up);
> >
> > if (err) {
> > ufshcd_uic_hibern8_exit(hba);
> >
> > --
> > 2.34.1
> >
> >
>
> Once fixed.

Sure, we can bubble up the error log here. Will update in patchset v2.

>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
>