Message-ID: <CAHk-=wheQNiW_WtHGO7bKkT7Uib-p+ai2JP9M+z+FYcZ6CAxYA@mail.gmail.com>
Date: Thu, 22 Jan 2026 10:07:56 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Maxime Ripard <mripard@...hat.com>
Cc: Uwe Kleine-König <u.kleine-koenig@...libre.com>, 
	linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michal Wilczynski <m.wilczynski@...sung.com>, Richard Genoud <richard.genoud@...tlin.com>
Subject: Re: [GIT PULL] pwm: Two fixes and a maintainer update

On Thu, 22 Jan 2026 at 06:39, Maxime Ripard <mripard@...hat.com> wrote:
>
> >
> > Obviously some changes are more likely to be user-visible than others,
> > so people should take that into account in how careful you need to be
> > about a patch.
>
> Where do we draw the line then, if there's any?

Users complaining is the only real line in the end.

So something like a test-suite complaining is then often a *very* good
indication that maybe users will hit some problem, and test suite
issues should be taken very seriously just because they might be the
first sign of upcoming trouble, and the earlier something is caught
and fixed, the easier it's going to be.

But a test-suite error isn't necessarily where you have to draw the
line - it's a big red flag, but it *could* be something like "the
error checking was done in a different order, and the error number
changed in some situations, but it doesn't actually change behavior
except for the error message that is printed".

So then a test suite failure is a "let's ignore it, but keep an eye on
it in case some program really did care about that *particular* error
number".

But a user complaining should basically result in an immediate fix -
possibly a "revert and rethink".

So a user complaining about some kernel change breaking their flow is
when you don't even start arguing. The issue is over and done, and the
change needs to be undone.

There are _very_ few exceptions to that rule, the main one being "the
problem was a fundamental huge and gaping security issue and we *had*
to make that change, and we couldn't even make your limited use-case
just continue to work".

The other exception is "the problem was reported years after it was
introduced, and now most people rely on the new behavior".

But starting to argue about users reporting breaking changes is
basically the final line for me. I have a couple of people that I have
in my spam block-list and refuse to have anything to do with, and they
have generally been about exactly that.

Note how it's not about making mistakes and _causing_ the regression.
That's normal. That's development. But then arguing about it is a
no-no.

So in the kernel tree, we don't argue about regressions. We fix them.
That's basically the only really hard rule I have.

Almost everything else is "just explain it, we have various rules for
development, but rules are meant to be broken". Not the user-reported
regression one.

> Should we just consider those drivers "wrong", treat it as a bugfix, and
> expect userspace applications to request the format they actually rely
> on? Or should we continue what we've tried to do and try to support the
> right format, and the old format for backward compatibility?

If it used to work, and people relied on it, you add a new "right"
format, and keep the old one around. Possibly with some hack to only
affect some particular special case, with the hope that the special
case and hack can be removed.

Now, if it's one or two users and you can just get them to recompile,
that's one thing. Niche hardware and odd use-cases can sometimes be
solved that way, and regressions can sometimes be fixed by handholding
every single reporter if the reporter is willing and able to change
his or her workflow.

But the basic rule is: be so good about backwards compatibility that
users never have to worry about upgrading. They should absolutely feel
confident that any kernel-reported problem will either be solved, or
have an easy solution that is appropriate for *them* (ie a
non-technical user shouldn't be expected to be able to do a lot).

Because the last thing we want is people holding back from trying new kernels.

                  Linus

Powered by blists - more mailing lists