Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
References: <20230529133433.56215-1-frank@oltmanns.dev>
 <69a0b07442116b52e359534d93433f55.sboyd@kernel.org>
From:   Frank Oltmanns <frank@oltmanns.dev>
To:     Stephen Boyd <sboyd@kernel.org>
Cc:     Michael Turquette <mturquette@baylibre.com>,
        Abel Vesa <abelvesa@kernel.org>, Peng Fan <peng.fan@nxp.com>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        Jacky Bai <ping.bai@nxp.com>,
        Anson Huang <Anson.Huang@nxp.com>, linux-clk@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: fractional-divider: Improve approximation when
 zero based
In-reply-to: <69a0b07442116b52e359534d93433f55.sboyd@kernel.org>
Date:   Tue, 13 Jun 2023 10:40:33 +0200
Message-ID: <875y7r21ry.fsf@oltmanns.dev>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Hi Stephen,

On 2023-06-12 at 14:39:00 -0700, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Frank Oltmanns (2023-05-29 06:34:33)
>> Consider the CLK_FRAC_DIVIDER_ZERO_BASED flag when finding the best
>> approximation for m and n. By doing so, increase the range of valid
>> values for the numerator and denominator by 1.
>>
>> Cc: A.s. Dong <aisheng.dong@nxp.com
>> Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
>> ---
>> I stumpled upon this, when familiarizing myself with clk drivers. Unfortunately,
>> I have no boards to test this patch. It seems the only user of this flag in
>> mainline is drivers/clk/imx/clk-composite-7ulp.c, therefore I'm cc-ing
>> get_maintainers.pl --git-blame -f drivers/clk/imx/clk-composite-7ulp.c
>> in the hopes of a wider audience.
>>
>> Thank you for considering this contribution,
>
> Thanks for looking at this. Can you add a kunit test (or a suite of
> tests) to confirm that this doesn't break existing functionality and
> also improves a case that would have failed or been suboptimal before?

Thank you for your feedback, I've submitted a V2 that contains the
tests:

https://lore.kernel.org/lkml/20230613083626.227476-1-frank@oltmanns.dev/

Thanks,
  Frank