The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Quentin Schulz <quentin.schulz@cherry.de>
Cc: Alexey Charkov <alchark@flipper.net>,
	 Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	 Brian Masney <bmasney@redhat.com>,
	Heiko Stuebner <heiko@sntech.de>,
	 Wyon Bi <bivvy.bi@rock-chips.com>,
	Finley Xiao <finley.xiao@rock-chips.com>,
	 Elaine Zhang <zhangqing@rock-chips.com>,
	Detlev Casanova <detlev.casanova@collabora.com>,
	 Sugar Zhang <sugar.zhang@rock-chips.com>,
	YouMin Chen <cym@rock-chips.com>,
	 Dragan Simic <dsimic@manjaro.org>,
	Liang Chen <cl@rock-chips.com>,
	linux-clk@vger.kernel.org,  linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement
Date: Wed, 22 Jul 2026 15:43:57 +0200	[thread overview]
Message-ID: <amDC9ZfBAD2xbhqa@venus> (raw)
In-Reply-To: <b0111164-3726-4a1b-bc3a-0e678ea2ecad@cherry.de>

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@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.

Greetings,

-- Sebastian

  parent reply	other threads:[~2026-07-22 13:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 19:17 [PATCH] clk: rockchip: Fractional PLL coefficient on RK3588/RK3576 is two's complement Alexey Charkov
2026-07-22 10:35 ` Quentin Schulz
2026-07-22 11:00   ` Alexey Charkov
2026-07-22 12:59     ` Quentin Schulz
2026-07-22 13:42       ` Alexey Charkov
2026-07-22 13:43       ` Sebastian Reichel [this message]
2026-07-22 13:54         ` Alexey Charkov
2026-07-22 16:15           ` Sebastian Reichel
2026-07-22 16:23     ` Heiko Stübner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amDC9ZfBAD2xbhqa@venus \
    --to=sebastian.reichel@collabora.com \
    --cc=alchark@flipper.net \
    --cc=bivvy.bi@rock-chips.com \
    --cc=bmasney@redhat.com \
    --cc=cl@rock-chips.com \
    --cc=cym@rock-chips.com \
    --cc=detlev.casanova@collabora.com \
    --cc=dsimic@manjaro.org \
    --cc=finley.xiao@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=quentin.schulz@cherry.de \
    --cc=sboyd@kernel.org \
    --cc=sugar.zhang@rock-chips.com \
    --cc=zhangqing@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox