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

[Michal Simek <michal.simek@xilinx.com>]

Hi,

On 4/22/21 7:48 AM, Punit Agrawal wrote:
> Hi Arnd,
> 
> Thanks for the fix.
> 
> Arnd Bergmann <arnd@kernel.org> writes:
> 
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> 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@arndb.de>
>> ---
>>  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@toshiba.co.jp>

I think code should be checked that these error values are handled how
they should be handled.

Thanks,
Michal