Re: [PATCH v4 6/9] clk: sunxi-ng: div: add read-only operation support

[Jerome Brunet <jbrunet@baylibre.com>]

On lun. 06 juil. 2026 at 10:06, sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Inconsistent rate calculation between `determine_rate` and `recalc_rate` due to division order.
> --
>
> commit 39f872462c04ad724c3624b152234160de56a47e
> Author: Jerome Brunet <jbrunet@baylibre.com>
>
> clk: sunxi-ng: div: add read-only operation support
>
> Add support for sunxi-ng read-only dividers. This will be
> useful to the a733 oscillator detection logic.
>
>> diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
>> index 62d680ccb524b..d1c8c7baa12dc 100644
>> --- a/drivers/clk/sunxi-ng/ccu_div.c
>> +++ b/drivers/clk/sunxi-ng/ccu_div.c
> [ ... ]
>> @@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
>>  					     req, ccu_div_determine_rate_helper, cd);
>>  }
>>  
>> +static int ccu_rodiv_determine_rate(struct clk_hw *hw,
>> +				    struct clk_rate_request *req)
>> +{
>> +	struct ccu_div *cd = hw_to_ccu_div(hw);
>> +	unsigned long val;
>> +	u32 reg;
>> +	int ret;
>> +
>> +	reg = readl(cd->common.base + cd->common.reg);
>> +	val = reg >> cd->div.shift;
>> +	val &= (1 << cd->div.width) - 1;
>> +
>> +	req->rate = ccu_mux_helper_unapply_prediv(&cd->common, &cd->mux, -1,
>> +						  req->rate);
>> +
>> +	if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>> +		req->rate *= cd->fixed_post_div;
>> +
>> +	ret = divider_ro_determine_rate(hw, req, cd->div.table,
>> +					cd->div.width, cd->div.flags, val);
>> +
>> +	if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
>> +		req->rate /= cd->fixed_post_div;
>> +
>> +	req->rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
>> +						req->rate);
>
> [Severity: Medium]
> Will this division order cause inconsistent rate calculations compared to
> ccu_div_recalc_rate()?
>
> The divider_ro_determine_rate() helper applies DIV_ROUND_UP() to the unadjusted
> parent rate, and then this function divides that result by fixed_post_div and
> prediv.
>
> However, ccu_div_recalc_rate() applies prediv to the parent rate first, then
> calculates the divider rate, and finally divides by fixed_post_div.
>
> Since the Common Clock Framework requires determine_rate and recalc_rate to be
> mathematically consistent, could this discrepancy cause rate mismatches or
> warnings for clocks using a pre-divider or fixed post-divider?

I think the RO side is correct and RW one is not.

The RO part correctly walk back the tree by un-applying the predivider
so, whatever CCF does with the parent rate value will be correct.

The RW part query the parent rate then applies the prediv. This
will be thrown away when/if clk_divider_bestdiv() calls
clk_hw_round_rate() on the parent. If that happens, the subsequent
un-apply of the prediv would make the matter even worse. So (if I
understand all this correctly) this case does not happen yet, otherwise
we would have noticed, and it can be fixed separately.

Side Note: I've not followed the sunxi history behind all those
prediv/postdiv but I find them a bit confusing. It seems like inserting
some fixed factor clocks in the clock trees would accomplish the same
thing while simplifying mux/divider quite a lot by droping these quirks ?

Side Note #2: I feel that while sashiko is pointing out valid things but we
are slowly getting off topic and down the rabbit hole with it ...

>
>> +
>> +	return ret;
>> +}
>> +

-- 
Jerome