From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11828C636CC for ; Mon, 13 Feb 2023 08:45:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eeXxhYMjZn4cL8A0UzLzYXLFWaVS2TqYlYRvNDv50+c=; b=Cil4n8XwJc+bFy qfLVGV4+hNTTj0SWWIE4JF/8sd1MqGMg8YGFo+z9dUIjavZON19bBya3na4/WUOdu0d4ru8crpgKc y6Kmx6TCncKSp+gAT60Om5sNUb3agWUQPEbYNS95oLEu1yg9SOZxxzHIB8ThVQx0rSuwUrSBQZGnR yZ8O2Kw/lnRSnBRFWBj0rkPrg812PeVYKhVGuawzKus/5o+tqcWIPY7jo9hyxdcK2fV4AwmXmFrpA hdWesUo25q2MMsXhFGVEGe8nOye/U93w2iLn94N5zS77eMOoeT0J26bVtVT4j2D/vnknDCQnFkXH5 W328z2pnu0klVpbUJqpA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRUR5-00De52-6v; Mon, 13 Feb 2023 08:43:43 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRUR1-00De3v-7P for linux-arm-kernel@lists.infradead.org; Mon, 13 Feb 2023 08:43:41 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E9A1432008FD; Mon, 13 Feb 2023 03:43:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 13 Feb 2023 03:43:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1676277813; x= 1676364213; bh=bJwx7IwzH47R8jsBNLlGfXE6Uds64AApY/i7ejI6wdY=; b=U FYN2TUhUNbrI2a4xXJ9XQy3WUoEIlCJdxOpqzVfnoFnQBeoAgjZHQqosBmfN1Zf/ q0Ay0VQgfRsA0sj3AhuCol9MlTRScMqIPrP0EoFuuZ+k5khwpiptTJkOvjKG4Vgt MZvT13s9fFkjIQqj/xGkulimec0zjDnlMHxcf30DPf9TQH2d7DXPCkd4EESoi2y+ p/3imwDbmqIbYjLgvdDCo/s49kpPZLZA9VaTL2+nykMUMYt6Z7gS6nRBMCYJ/hqd oOGcdVsmZrQapxCoM8a95zyOjWNWq/Qwkb/G3lItKEpuGCgggGc9FRCPU7u5tC99 kyRheWd5Twb3M1Ay/3X1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676277813; x= 1676364213; bh=bJwx7IwzH47R8jsBNLlGfXE6Uds64AApY/i7ejI6wdY=; b=I GcI7/1iGpjUEPD53awGngS3YgMN5cNldEbBl+Ci8jGrlPxJwqh2tNhrHqwHO6SnH QPqGl6QQu2Dm0o8KrywfQ3OT8fjTM+aSTHeXTPvBXXedObvZw+ROOd8zI56HXjrW eFIqx/vs2oKcWtmOzpizZiZOUylfS7Y/PiscK+BQTXK5mgJ2dQVore2cdK4BLfGk iQ8HSOuB8Vjp5op2LM6YZP1lcwf+cB++T7ZUF1AUjUNuLdTyEH54ef6r+vzW/SZK K9ZuJh9Co/5YNm2OPjTPRt+5ogGpSaZFDow4H0v0B6oCKOROr12l96Tk0VqkE2x8 h6Kv05srKdDUsVGklGQJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeitddguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtugfgjgesthhqredttddtudenucfhrhhomhepofgr gihimhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtf frrghtthgvrhhnpeelleefieelleetteefvdeikeeffeffvefhtdevgfehveduveehjedv vdeiledtieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Feb 2023 03:43:32 -0500 (EST) Date: Mon, 13 Feb 2023 09:43:29 +0100 From: Maxime Ripard To: Andre Przywara Cc: Andreas Feldner , Andreas Feldner , Rob Herring , Krzysztof Kozlowski , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ARM: dts: allwinner: minimize irq debounce filter per default Message-ID: <20230213084329.ulckaigwd7dof37u@houat> References: <20230207011608.2ce24d17@slackpad.lan> <20230209202952.673d5a60@slackpad.lan> <20230210082936.qefzz4fsp3jpalvp@houat> <20230210094425.474cfba5@donnerap.cambridge.arm.com> <20230210100620.z6j7rvkiwyu7paij@houat> <20230210101814.2d36ae57@donnerap.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230210101814.2d36ae57@donnerap.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230213_004339_600872_0379F12B X-CRM114-Status: GOOD ( 28.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Feb 10, 2023 at 10:18:14AM +0000, Andre Przywara wrote: > > > Not sure if you were actually arguing this, but the change I sketched > > > above (interpreting 0 as 24MHz/1) is separate though, as the current > > > default is "no DT property", and not 0. There is no input-debounce > > > property user in the kernel tree at the moment, so we wouldn't break > > > anyone. The only thing that would change is if a downstream user was > > > relying on "0" being interpreted as "skip the setup", which isn't > > > really documented and could be argued to be an implementation detail. > > > = > > > So I'd suggest to implement 0 as "lowest possible", and documenting t= hat > > > and the 32KHz/1 default if no property is given. = > > = > > Ah, my bad. > > = > > There's another thing to consider: there's already a generic per-pin > > input-debounce property in pinctrl. > > = > > Since we can't control it per pin but per bank, we moved it to the > > controller back then, but there's always been this (implicit) > > expectation that it was behaving the same way. > > = > > And the generic, per-pin, input-debounce documentation says: > > = > > > Takes the debounce time in usec as argument or 0 to disable debouncin= g = > > = > > I agree that silently ignoring it is not great, but interpreting 0 as > > the lowest possible is breaking that behaviour which, I believe, is a > > worse outcome. > = > Is it really? If I understand the hardware manuals correctly, we cannot > really turn that feature off, so isn't the lowest possible time period (24 > MHz/1 at the moment) the closest we can get to "turn it off"? So > implementing this would bring us actually closer to the documented > behaviour? Or did I get the meaning of this time period wrong? > At least that's my understanding of how it fixed Andreas' problem: 1=B5s > is still not "off", but much better than the 31=B5s of the default. The n= ew > 0 would then be 0.041=B5s. My point was that the property we share the name (and should share the semantics with) documents 0 as disabled. We would have a behavior that doesn't disable it. It's inconsistent. The reason doesn't really matter, we would share the same name but have a completely different behavior, this is super confusing to me. Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel