linux-kernel - Re: [PATCH] pinctrl: sunxi: Use minimal debouncing period as default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Zz20dquzl5_2_3TQ@collins>
Date: Wed, 20 Nov 2024 11:05:42 +0100
From: Paul Kocialkowski <paulk@...-base.io>
To: Maxime Ripard <mripard@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Uwe Kleine-König <ukleinek@...nel.org>,
	Chen-Yu Tsai <wens@...e.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Samuel Holland <samuel@...lland.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Paul Kocialkowski <contact@...lk.fr>
Subject: Re: [PATCH] pinctrl: sunxi: Use minimal debouncing period as default

Le Wed 20 Nov 24, 09:01, Maxime Ripard a écrit :
> On Tue, Nov 19, 2024 at 07:47:43PM +0100, Paul Kocialkowski wrote:
> > > > In any case I don't think it makes sense for the platform code to impose
> > > > what a reasonable period for interrupts is (especially with such a large
> > > > period as default).
> > > 
> > > So you don't think it makes sense for the platform code to impose a
> > > reasonable period, so you want to impose a (more, obviously) reasonable
> > > period?
> > 
> > Yes absolutely. Anything that brings us closer to "you get what is really
> > happening with the hardware". The sunxi controller doesn't allow disabling
> > debouncing entirely, so the next best thing is to have it with the smallest
> > period.
> 
> That's an opinion, not a fact.

Yes and I'm trying to explain why I believe this is the most sensible opinion
here. I'm not saying everyone *has to* agree with me.

> > > If anything, the status quo doesn't impose anything, it just rolls with
> > > the hardware default. Yours would impose one though.
> > 
> > The result is that it puts a strong limitation and breaks many use cases by
> > default. I don't think we have to accept whatever register default was chosen
> > by hardware engineers as the most sensible default choice and pretend that this
> > is not a policy decision.
> 
> You're making it much worse than it is. It doesn't "break many use
> cases" it broke one, by default, with a supported way to unbreak it, in
> 12 years.

I think this is exaggerated. Like I mentioned previously there are *many*
situations that are not covered by the default. The fact that I'm the first
person to bring it up in 12 years doesn't change that.

Sofar the downside you brought up boils down to: badly-designed hardware may
have relied on this mechanism to avoid interrupt storms that could prevent
the system from booting.

If that happens people can always increase the debouncing time with the
property as they need.

My point here is that the property should be used to accommodate for
broken hardware and that the default should work for most use cases,
including things as simple as an off-the-shelf sensor board.

That's all.

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Specialist in multimedia, graphics and embedded hardware support with Linux.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)