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

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

[Uwe Kleine-König]

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

Hello Linus,

the following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:

  Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/pwm/for-6.19-rc7-fixes

for you to fetch changes up to 0a155a8a24ddc647aaf28ce7cdb14af7270c158f:

  MAINTAINERS: Add myself as reviewer for PWM rust drivers (2026-01-20 09:53:18 +0100)

The commit that triggered this pull request is the ioctl one that I
consider critical to get in. I only noticed this problem recently, so
it's not in next yet, but it should be obvious and simple enough to be
correct.

I wouldn't have bothered you for the other two changes alone, but sent
them along now that there is a fixes PR. These are both not very
critical, but also simple enough to not have to fear regressions. The
max7360 commit also sat in next since next-20260116 with a different
commit id (i.e. 3bbf529821f64cebad9f385af19e149a9dfffead) as I initially
thought to not send it to you and now had to rebase it to not include
merge window material. The other patch is just an update to MAINTAINERS
to prevent people sending rust pwm patches without cc:ing Michal.

Thanks for pulling this for 6.19-rc7.

Best regards from Germany
Uwe

----------------------------------------------------------------
pwm: Two fixes and a maintainer update

Included here are three changes:

 - pwm: Ensure ioctl() returns a negative errno on error
   This affects two ioctls on /dev/pwmchipX where the return value of
   copy_to_user() was passed to userspace. This is fixed to return
   -EFAULT now instead.
   You might argue that this is an ABI change, but I still think it's
   sensible to be fixed because a) other exit paths already return
   -EFAULT so userspace must be aware of this return value; b) the
   interface is somewhat new (commit v6.17-rc1~181^2~35 ("pwm: Add
   support for pwmchip devices for faster and easier userspace access"))
   and the only known user is libpwm which relies on the fixed
   semantics (and uses the ioctl correctly and thus doesn't trigger that
   problematic error path); and c) it's very unlikely that
   copy_to_user() fails if a moment before copy_from_user() on the same
   memory chunk succeeded.

 - pwm: max7360: Populate missing .sizeof_wfhw in max7360_pwm_ops
   This fixes an oversight in commit v6.18-rc1~168^2~3^2~6 which added
   support for the max7360 driver. There is no user-visible effect
   because the .sizeof_wfhw member is just a safe guard that the memory
   provided by the core is big enough. While it currently is big enough
   and there is no reason to assume that will change, doing that
   correctly is necessary.

 - MAINTAINERS: Add myself as reviewer for PWM rust drivers
   "Myself" here is Michal Wilczynski who cares for the Rust parts of
   the pwm subsystem. Several of the patches sent recently for the (for
   now) only Rust pwm driver did not add Michal to Cc which resulted in
   the patches waiting for review as I thought Michal would care but he
   wasn't aware of them.

----------------------------------------------------------------
Michal Wilczynski (1):
      MAINTAINERS: Add myself as reviewer for PWM rust drivers

Richard Genoud (1):
      pwm: max7360: Populate missing .sizeof_wfhw in max7360_pwm_ops

Uwe Kleine-König (1):
      pwm: Ensure ioctl() returns a negative errno on error

 MAINTAINERS               |  4 ++++
 drivers/pwm/core.c        | 10 ++++++----
 drivers/pwm/pwm-max7360.c |  1 +
 3 files changed, 11 insertions(+), 4 deletions(-)

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

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

[Linus Torvalds]

On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-König
<u.kleine-koenig@baylibre.com> wrote:
>
>    You might argue that this is an ABI change [..]

Pretty much any change can be an ABI change - even totally new
interfaces change behavior in that something that didn't use to do
anything now does something.

And we've actually very much have had things like that happen too,
when broken user space did something odd, and adding a completely new
file in /proc (or something like that) just broke broken user space.

And any bugfix that changes visible behavior is also an "ABI change",
and so there is no practical meaning to the whole otion.

So I absolutely detest the whole notion of "ABI changes". It's a
meaningless concept, and I hate it with a passion, because it then
results in the "opposite" situation where some projects seem to think
that ABI changes are perfectly fine as long as they go along with
version number changes.

The Linux rule for regressions is basically based on the philosophical
question of "If a tree falls in the forest, and nobody is around to
hear it, does it make a sound?".

So the only thing that matters is if something breaks user-*conscious* behavior.

And when that happens, the distinction between "bug fix" and "new
feature" and "ABI change" matters not one whit, and the change needs
to be done differently.

Anyway, I agree that the whole "return proper -EFAULT on user copy
failures" is clearly the right thing to do, and I do not disagree with
the patch at all.

I just wanted to point out that the argument about whether it's an ABI
change or not is irrelevant. If it turns out that some program - not a
test script, but something with relevance to conscious user
expectations - depended on the old broken behavior, then it needs to
be done some other way.

So whether somebody "argues" that the change is an ABI change or not
is simply not relevant to anything.

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.

This one looks entirely benign, but I wanted to point out that if it
breaks some program - however unlikely that is - it just needs to be
reverted, and it doesn't matter what the change is called.

                     Linus

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

[Uwe Kleine-König]

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

Hello Linus,

On Tue, Jan 20, 2026 at 10:11:27AM -0800, Linus Torvalds wrote:
> On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> >    You might argue that this is an ABI change [..]
> 
> [...]
> 
> This one looks entirely benign, but I wanted to point out that if it
> breaks some program - however unlikely that is - it just needs to be
> reverted, and it doesn't matter what the change is called.

Thanks for your feedback, that matches what I think. I just thought it a
good idea to motivate the change well, given it's that late in the
development cycle and I didn't want you to yell at me for trying to hide
something :-D

Best regards
Uwe

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

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

[pr-tracker-bot]

The pull request you sent on Tue, 20 Jan 2026 10:32:26 +0100:

> https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git tags/pwm/for-6.19-rc7-fixes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8f7537efbe5636a798cf885ea2fa0e4889995fa9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

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

[Maxime Ripard]

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

Hi,

Going a bit off topic here, sorry.

On Tue, Jan 20, 2026 at 10:11:27AM -0800, Linus Torvalds wrote:
> On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> >
> >    You might argue that this is an ABI change [..]
> 
> Pretty much any change can be an ABI change - even totally new
> interfaces change behavior in that something that didn't use to do
> anything now does something.
> 
> And we've actually very much have had things like that happen too,
> when broken user space did something odd, and adding a completely new
> file in /proc (or something like that) just broke broken user space.
> 
> And any bugfix that changes visible behavior is also an "ABI change",
> and so there is no practical meaning to the whole otion.
> 
> So I absolutely detest the whole notion of "ABI changes". It's a
> meaningless concept, and I hate it with a passion, because it then
> results in the "opposite" situation where some projects seem to think
> that ABI changes are perfectly fine as long as they go along with
> version number changes.
> 
> The Linux rule for regressions is basically based on the philosophical
> question of "If a tree falls in the forest, and nobody is around to
> hear it, does it make a sound?".
> 
> So the only thing that matters is if something breaks user-*conscious* behavior.
> 
> And when that happens, the distinction between "bug fix" and "new
> feature" and "ABI change" matters not one whit, and the change needs
> to be done differently.
> 
> Anyway, I agree that the whole "return proper -EFAULT on user copy
> failures" is clearly the right thing to do, and I do not disagree with
> the patch at all.
> 
> I just wanted to point out that the argument about whether it's an ABI
> change or not is irrelevant. If it turns out that some program - not a
> test script, but something with relevance to conscious user
> expectations - depended on the old broken behavior, then it needs to
> be done some other way.
> 
> So whether somebody "argues" that the change is an ABI change or not
> is simply not relevant to anything.
> 
> 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?

I have a particular example in mind with v4l2. With some drivers, and
because pixel order naming is confusing and inconsistent in the media
industry as a whole, we ended up with drivers capturing framebuffers
with the wrong pixel order (blue and red inverted) compared to
documented order for the format they were requesting. And rejecting the
format with the "right" order.

We've been tip-toeing about this to fix it in order to avoid any
regression in some tools.

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?

Thanks!
Maxime

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

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

[Linus Torvalds]

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.

                  Linus

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

[Maxime Ripard]

[-- 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 --]

"immediate fixes" for user-reported regressions (was: Re: [GIT PULL] pwm: Two fixes and a maintainer update)

[Thorsten Leemhuis]

On 1/22/26 19:07, Linus Torvalds wrote:

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

So how can I/we make "immediate fixes" happen more often without
contributing to maintainer burnout?

Because I see quite a few user-reported regressions that take quite a
while to get resolved. I usually tried prodding maintainers, but well,
that led to major complaints reg. maintainer burnout and in one case
contributed to a maintainer stepping down. And many of those complaints
even happened with simple cases, like me prodding when (a) fixes/reverts
with a Tested-by: from the reporter were waiting on the list for review
and merging for one or two weeks or (b) were merged in the right
subsystem tree already for a similar timeframe and just not sent along.

And I can even understand that, as maintainers have a lot on their plate
already and sometimes need a break, too.

We could obviously start bypassing the regular channels occasionally
when no "immediate fix" comes forward through them if that's what you
want. I could, for example, point you to fixes for recent regressions or
even collect and send them your way when they fall into one of these
categories:
- Reverts that I or someone else submitted that got a Tested-by: from
the reporter.
- Unreviewed fixes that got a Tested-by: from the reporter and no "this
is all wrong" complaints from the developers within a two or three days.
- Fixes cherry-picked from the subsystem trees not sent along.
- Fixes maintainers ask me to pick up to send along.

But well, bypassing the regular channels obviously has it's downsides,
as things are more likely to get wrong that way. But I guess if you
really want "immediate fixes" for user-reported regressions, we afaics
likely need something like that. Unless you have a better idea.

Ciao, Thorsten

Re: "immediate fixes" for user-reported regressions (was: Re: [GIT PULL] pwm: Two fixes and a maintainer update)

[Linus Torvalds]

On Wed, 28 Jan 2026 at 08:12, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> So how can I/we make "immediate fixes" happen more often without
> contributing to maintainer burnout?

This is partly why I mentioned the "revert and rethink" model. A lot
of maintainers already do that for late regressions because they don't
want to have a hurried fix late in the rc, but I think it's just often
a good idea in general unless there's just an obvious fix for an
obvious bug (and often it really is obvious once somebody reports
problems and the commit that caused them has been pinpointed).

Exactly so that maintainers don't get stressed out over having a
pending problem report that people keep pestering them about.

I think people are sometimes a bit too bought into whatever changes
they made, and reverting is seen as "too drastic", but I think it's
often the quick and easy solution for when there isn't some obvious
response to a regression report.

It's also worth noting that "immediate" obviously doesn't mean "right
this *second* when the problem has been reported".

But if it's a regression with a known commit that caused it, I think
the rule of thumb should generally be "within a week", preferably
before the next rc.

> We could obviously start bypassing the regular channels occasionally
> when no "immediate fix" comes forward through them if that's what you
> want.

I do actually do that when something hasn't been fixed and people
point out a known fix (or revert) that has been pending for weeks and
causes problems for people.

Of course, by the time something is at the point where it's been
escalated to me, it usually means that it's really been _way_ too
long. So that's not the good case.

                Linus