[PATCH] ufs: uclass: fix potential unitialised use

[Marek Vasut]

On 1/8/26 9:44 PM, Casey Connolly wrote:

>>>> ""
>>>> diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c
>>>> index 3c8e4299259..da46b3ebdfd 100644
>>>> --- a/drivers/ufs/ufs-uclass.c
>>>> +++ b/drivers/ufs/ufs-uclass.c
>>>> @@ -1868,12 +1868,11 @@ static int ufshcd_set_dev_ref_clk(struct ufs_hba
>>>> *hba)
>>>>           }
>>>>
>>>>           host_ref_clk_freq = ufshcd_parse_dev_ref_clk_freq(hba,
>>>> ref_clk);
>>>> -       if (host_ref_clk_freq == REF_CLK_FREQ_INVAL)
>>>> +       if (host_ref_clk_freq == REF_CLK_FREQ_INVAL) {
>>>>                   dev_err(hba->dev,
>>>>                           "invalid ref_clk setting = %ld\n",
>>>> clk_get_rate(ref_clk));
>>>> -
>>>> -       if (host_ref_clk_freq == REF_CLK_FREQ_INVAL)
>>>> -               goto out;
>>>> +               return -EINVAL; // I think we want to bail with error ?
>>>
>>> I don't think we need to error out here, Qualcomm platforms don't have
>>> this ref clk wired up properly yet but somehow things are working ok.>
>>> +       }
>> This will print a warning. If on qualcomm platforms the UFS is working
>> and these clock are not needed, then this should be fixed, likely by
>> making the clock optional, or using fixed-clock in DT ?
> 
> I think the warning is what we want, it will be fixed properly once we
> get a driver for rpmhcc which is what provides the ref clk. As for why
> UFS works despite this I have no idea but I'd rather assume it's a lucky
> accident.
So, would it be possible to add fixed-clock into the 
qualcomm-*-u-boot.dtsi in the meantime to avoid this conditional, and 
return -EINVAL here ; and once the rpmhcc driver is available, remove 
the qualcomm-*-u-boot.dtsi change ?