All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Linus Walleij <linusw@kernel.org>, Tj <tj.iam.tj@proton.me>,
	 Hans de Goede <hansg@kernel.org>,
	metux IT consult <info@metux.net>,
	 platform-driver-x86@vger.kernel.org
Subject: Re: pcengines_apuv2: LEDs/Input fails since v6.18
Date: Wed, 18 Feb 2026 13:04:48 -0800	[thread overview]
Message-ID: <aZYpArgUKvxtibzS@google.com> (raw)
In-Reply-To: <CAMRc=Md3kUVOEshvPiwv=xvRRNwQndcP=hsbyMOJn4c2=+CaiA@mail.gmail.com>

On Wed, Feb 18, 2026 at 09:21:14PM +0100, Bartosz Golaszewski wrote:
> On Wed, Feb 18, 2026 at 6:25 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> >
> > > >
> > > > I think the patch below should fix it.
> > > >
> > > > Bartosz, I think you should revert
> > > > 86ef402d805d606a10e6da8e5a64a51f6f5fb7e2 until after you audit all
> > > > existing gpio drivers. Breakign the kernel like that is not great.
> > > >
> > >
> > > Hi Dmitry!
> > >
> > > This change has been upstream for close to a year - it first appeared
> > > in v6.15-rc1. There have been very few reports (I think a couple
> > > initially and then none for months) and fixing this is typically
> > > trivial. It addressed an actual problem where these retvals would be
> > > propagated to user-space and misinterpreted. I think we should fix
> > > this driver and keep this change. "Auditing" typically means never
> > > fixing things entirely.
> >
> > [+LinusW as co-maintainer]
> >
> > That's ... an interesting stance. You couldn't even bother going
> > through your own subsystem before applying a change that could break
> > user's systems.
> >
> 
> My stance is that I don't want a knee-jerk reaction of reverting a
> valid change after one report (with a fix queued) several months after
> the change was made. If more people start complaining then I won't
> oppose a revert.

I think you are witnessing that outside of "common" x86 devices there is
significant lag between the latest kernel release and what people are
actually using on their systems.

Thanks.

-- 
Dmitry

      reply	other threads:[~2026-02-18 21:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-16 19:01 pcengines_apuv2: LEDs/Input fails since v6.18 Tj
2026-02-17 11:42 ` Hans de Goede
2026-02-17 15:25   ` Tj
2026-02-17 17:29     ` Dmitry Torokhov
2026-02-17 19:34       ` Tj
2026-02-18  9:55       ` Bartosz Golaszewski
2026-02-18 17:25         ` Dmitry Torokhov
2026-02-18 19:36           ` Dmitry Torokhov
2026-02-18 20:21           ` Bartosz Golaszewski
2026-02-18 21:04             ` Dmitry Torokhov [this message]

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=aZYpArgUKvxtibzS@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=brgl@kernel.org \
    --cc=hansg@kernel.org \
    --cc=info@metux.net \
    --cc=linusw@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tj.iam.tj@proton.me \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.