[PATCH] clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement

[Alexey Charkov]

Hi Sebastian,

On Wed, Jul 22, 2026 at 5:44 PM Sebastian Reichel
<sebastian.reichel at collabora.com> wrote:
>
> Hello Alexey,
>
> On Wed, Jul 22, 2026 at 02:59:25PM +0200, Quentin Schulz wrote:
> > On 7/22/26 1:00 PM, Alexey Charkov wrote:
> > > On Wed, Jul 22, 2026 at 2:35 PM Quentin Schulz <quentin.schulz at cherry.de> wrote:
> > > > On 7/21/26 9:17 PM, Alexey Charkov wrote:
> > > > > Not adding Cc stable, because while this fixes a real bug it's not a
> > > > > regression, as the issue was introduced in the same commit that added the
> > > > > RK3576/RK3588 support.
> > > >
> > > > I don't think this is a valid reason :)
> > >
> > > I believe Linus frowns upon changes like "it never worked, but we've
> > > fixed it now" being submitted as fixes. It's been broken for years,
> > > and since nobody complained yet, going via the normal development path
> > > (i.e. -next) seems perfectly fine to me.
> >
> > My bet is because of the Fixes: it'll get backported anyway even
> > if you don't put Cc: stable. In any case, I don't care too much :)
>
> FWIW you are mixing up things. Linus does not handle the stable
> kernels. He does the release candidates and the initial version of
> every kernel release. The stable releases are handled by the stable
> maintainers. Linus only said, that he does not want to get these
> kind of fixes during late -rc phase. That makes sense considering
> fixes also have a chance of introducing regressions.
>
> But if patches end up in a pull request for an -rc kernel or in the
> pull request for the next merge window depends on the maintainer
> applying the patch (i.e. Heiko). The maintainer can queue a patch
> with all those tags into the normal for-next queue targeting the
> following merge window. This results in the patch being in
> linux-next for a while, then being added to the master branch during
> a merge window and then being added to the stable trees (as stable
> only picks patches that are in mainline).
>
> The maintainer can also merge a patch to the queue for -rc kernels
> without the Cc stable. That is exactly what happens for a regression
> from a normal patch in the merge window, since the affected patch
> wouldn't be in any stable kernel.
>
> TLDR: The Cc stable tag has nothing to do with Linus.

Indeed, I made a logical leap here. In my view, however, this patch
doesn't need to go into 7.2 fixes (it wasn't broken during the 7.2
merge window), nor necessarily into stable backports (no-one seems to
have used the affected PLL rates in older kernels, so there is nothing
to fix for them either).

However, it will become relevant for driving arbitrary display clocks
for DP video output because several display modes (and consequently,
PLL rates) I needed for those monitors I tested require new table
entries with negative PLL coefficients. Those would be 7.3+ material
anyway.

Best regards,
Alexey