Re: [GIT PULL] pwm: Two fixes and a maintainer update

[Maxime Ripard <mripard@redhat.com>]

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

Hi,

On Thu, Jan 22, 2026 at 10:07:56AM -0800, Linus Torvalds wrote:
> On Thu, 22 Jan 2026 at 06:39, Maxime Ripard <mripard@redhat.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.

Ack, thanks a lot for your answer. We'll keep working on
backward-compatible version then :)

Maxime

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