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

[Sebastian Reichel <sebastian.reichel@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]

Hello Alexey,

On Wed, Jul 22, 2026 at 05:54:15PM +0400, Alexey Charkov wrote:
> On Wed, Jul 22, 2026 at 5:44 PM Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> > 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@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.

That's a different argument. FWIW I don't see any issues with not
Cc'ing stable. I suggest to put that info into the commit
description. E.g.:

While this patch fixes a few PLL rates, there are no known users of
the affected rates in the mainline kernel. Thus there is no need to
backport this. The fixed rate calculation will become relevant for
driving arbitrary display clocks for DP video output in the future.

That helps anyone to understand what is going on regarding stable
backport (incl. the bot).

Greetings,

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]