Re: [PATCH v2] clk: zynq: pll: Fix kernel-doc after determine_rate() conversion

On 8/3/26 08:31, Babanpreet Singh wrote:
> Commit 1547747b55d5 ("clk: zynq: pll: convert from round_rate() to
> determine_rate()") replaced zynq_pll_round_rate() with
> zynq_pll_determine_rate() but left its kernel-doc block behind, so the
> block still names the old function and documents the removed @rate and
> @prate parameters instead of @req.
> 
> Retitle the block and describe @req. The Return: line described a
> frequency and referenced the removed @rate; the function returns 0
> unconditionally and the rounded rate comes back in @req.
> 
> No functional changes.
> 
> Assisted-by: Claude:claude-opus-5 [kernel-doc]
> Signed-off-by: Babanpreet Singh <[email protected]>
> ---
> Changes in v2:
> - Say "Return: 0 always" instead of "Return: 0 on success". The function
>    has no failure path, so there is no success case to distinguish
>    (Michal Simek).
> - Rebased on v7.2-rc6; the file is unchanged, so the diff is the same
>    apart from that line.
> 
> v1: https://lore.kernel.org/all/[email protected]/
> 
>   drivers/clk/zynq/pll.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/zynq/pll.c b/drivers/clk/zynq/pll.c
> index 44c6093783641..fe90b50e1545d 100644
> --- a/drivers/clk/zynq/pll.c
> +++ b/drivers/clk/zynq/pll.c
> @@ -42,11 +42,11 @@ struct zynq_pll {
>   #define PLL_FBDIV_MAX	66
>   
>   /**
> - * zynq_pll_round_rate() - Round a clock frequency
> + * zynq_pll_determine_rate() - Round a clock frequency
>    * @hw:		Handle between common and hardware-specific interfaces
> - * @rate:	Desired clock frequency
> - * @prate:	Clock frequency of parent clock
> - * Return:	frequency closest to @rate the hardware can generate.
> + * @req:	Clock rate request, updated with the frequency closest to the
> + *		requested one that the hardware can generate
> + * Return:	0 always
>    */
>   static int zynq_pll_determine_rate(struct clk_hw *hw,
>   				   struct clk_rate_request *req)

Reviewed-by: Michal Simek <[email protected]>

Thanks,
Michal