Re: [PATCH] clk: zynqmp: fix compile testing without ZYNQMP_FIRMWARE

[Punit Agrawal]

Michal Simek <michal.simek@xxxxxxxxxx> writes:

> Hi,
>
> On 4/22/21 7:48 AM, Punit Agrawal wrote:
>> Hi Arnd,
>> 
>> Thanks for the fix.
>> 
>> Arnd Bergmann <arnd@xxxxxxxxxx> writes:
>> 
>>> From: Arnd Bergmann <arnd@xxxxxxxx>
>>>
>>> When the firmware code is disabled, the incomplete error handling
>>> in the clk driver causes compile-time warnings:
>>>
>>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>>> drivers/clk/zynqmp/pll.c:147:29: error: 'fbdiv' is used uninitialized [-Werror=uninitialized]
>>>   147 |         rate =  parent_rate * fbdiv;
>>>       |                 ~~~~~~~~~~~~^~~~~~~
>>> In function 'zynqmp_pll_get_mode',
>>>     inlined from 'zynqmp_pll_recalc_rate' at drivers/clk/zynqmp/pll.c:148:6:
>>> drivers/clk/zynqmp/pll.c:61:27: error: 'ret_payload' is used uninitialized [-Werror=uninitialized]
>>>    61 |         return ret_payload[1];
>>>       |                ~~~~~~~~~~~^~~
>>> drivers/clk/zynqmp/pll.c: In function 'zynqmp_pll_recalc_rate':
>>> drivers/clk/zynqmp/pll.c:53:13: note: 'ret_payload' declared here
>>>    53 |         u32 ret_payload[PAYLOAD_ARG_CNT];
>>>       |             ^~~~~~~~~~~
>>> drivers/clk/zynqmp/clk-mux-zynqmp.c: In function 'zynqmp_clk_mux_get_parent':
>>> drivers/clk/zynqmp/clk-mux-zynqmp.c:57:16: error: 'val' is used uninitialized [-Werror=uninitialized]
>>>    57 |         return val;
>>>       |                ^~~
>> 
>> 
>> Not sure what I am missing but I couldn't reproduce these warnings. I
>> tried a few different ways to toggle CONFIG_ZYNQMP_FIRMWARE.
>> 
>> Regardless...
>
> Me too. Can you share your .config file?
>
>> 
>>> As it was apparently intentional to support this for compile testing
>>> purposes, change the code to have just enough error handling for the
>>> compiler to not notice the remaining bugs.
>>>
>>> Fixes: 21f237534661 ("clk: zynqmp: Drop dependency on ARCH_ZYNQMP")
>>> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
>>> ---
>>>  drivers/clk/zynqmp/clk-mux-zynqmp.c | 4 +++-
>>>  drivers/clk/zynqmp/pll.c            | 8 ++++++--
>>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/clk/zynqmp/clk-mux-zynqmp.c b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> index 06194149be83..2afded3c7c11 100644
>>> --- a/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> +++ b/drivers/clk/zynqmp/clk-mux-zynqmp.c
>>> @@ -50,9 +50,11 @@ static u8 zynqmp_clk_mux_get_parent(struct clk_hw *hw)
>>>  
>>>  	ret = zynqmp_pm_clock_getparent(clk_id, &val);
>>>  
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() getparent failed for clock: %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return ret;
>
> return should be u8 and this can be negative value. That's why I think
> this should be fixed differently and all users should be checked that it
> is handled like that.
>
>
>>> +	}
>>>  
>>>  	return val;
>>>  }
>>> diff --git a/drivers/clk/zynqmp/pll.c b/drivers/clk/zynqmp/pll.c
>>> index abe6afbf3407..67d2a2d260c1 100644
>>> --- a/drivers/clk/zynqmp/pll.c
>>> +++ b/drivers/clk/zynqmp/pll.c
>>> @@ -54,9 +54,11 @@ static inline enum pll_mode zynqmp_pll_get_mode(struct clk_hw *hw)
>>>  	int ret;
>>>  
>>>  	ret = zynqmp_pm_get_pll_frac_mode(clk_id, ret_payload);
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() PLL get frac mode failed for %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return ret;
>>> +	}
>
> Return should be enum pll_mode which is 0 or 1 which is likely not done
> here.
>
>>>  
>>>  	return ret_payload[1];
>>>  }
>>> @@ -140,9 +142,11 @@ static unsigned long zynqmp_pll_recalc_rate(struct clk_hw *hw,
>>>  	int ret;
>>>  
>>>  	ret = zynqmp_pm_clock_getdivider(clk_id, &fbdiv);
>>> -	if (ret)
>>> +	if (ret) {
>>>  		pr_warn_once("%s() get divider failed for %s, ret = %d\n",
>>>  			     __func__, clk_name, ret);
>>> +		return -1ul;
>>> +	}
>
> Same here.
>
>
>>>  
>>>  	rate =  parent_rate * fbdiv;
>>>  	if (zynqmp_pll_get_mode(hw) == PLL_MODE_FRAC) {
>> 
>> The changes make sense in that the functions error out sensibly when the
>> zynqmp firmware driver is not enabled.
>> 
>> Acked-by: Punit Agrawal <punit1.agrawal@xxxxxxxxxxxxx>
>
> I think code should be checked that these error values are handled how
> they should be handled.

I only looked at it from the point of view of getting rid of the
warnings - based on the commit log, Arnd's patch is only taking care of
the compiler warnings when the driver is built with
CONFIG_COMPILE_TEST=y and likely CONFIG_ZYNQMP_FIRMWARE=n.

In practice, the code should not be hit at runtime due to the dependency
on the firmware driver. Even then, a better fix would indeed be taking
the returned values at call sites into account.

[...]