Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp515061pxb; Wed, 11 Nov 2020 09:11:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJz9mFo5kyGQZdwOuT0GP/UBs/peBFVNSm+DbRqEMT2KFn9+oKkeX0qjGvnLlaj6JW6+zX3/ X-Received: by 2002:a05:6402:234a:: with SMTP id r10mr410926eda.311.1605114676983; Wed, 11 Nov 2020 09:11:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605114676; cv=none; d=google.com; s=arc-20160816; b=qOLnYOmW79wN7Ie4MODLgIZY7EptaLKoJF48wT84wtnF3bWxBzgK5XfuPBj1sUXkdZ isvISOnIfy8oGhDCmzIZS06rSIr1kb2c1gPTNRPW2aztcBIncWRAMGUl1wKsjhsLBHWm PtzvqiYINO3Km9/8spqd0I58sdYBZMa4ndgVI2/v0vBggeaMtvOoKkBgum5i/Tt7TFsO xnAAeuuTMEUYkimtGK0Rz54dfKe49MOZx5VDwow7c6khm/pvzr4n7f/4V2vw8Euulhos V5JJEIqXFXDh7OHuvU/YLFEk2PXzWBWKfQCfR6m9FSL6+W3Q9DvFzF9Z7K9eS51G6ioj RGJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=FL6IeONOwxnR/eo3bjx7f+tS/GorEH38lUINVb++VnQ=; b=NtkRr6MWa7iQE80q79ahRuxfJRR9tSZ3ElxOST9r4wRQVqNHgJeBOEa0cMhx5PBbpR LZdXA9RhiDmB67o11qDagC7/rcO+EP43f2oRDUpelaySrCYGNF0xFsA+XhN1o+5H6tZ5 xk5Il+31HiZi9sazk3qg2I7L239IojS2lnTWK/xbXK9jYVNUyKYlxsmNM7g8SqJ1lXJ3 /RPTqWfruOCZEaGaRyEzCDVysL10WNSfeOjXIzXOHWHno0Ubnntelu4NYSFcyeN4GZQO MR6aPZNQA0l3+8Nk5G5HAG4KEdklTswx0t9mBOlWVhSqviyHY2L3F+1RfcRSMlTNPVu4 b4fg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v13si2693974edl.476.2020.11.11.09.10.40; Wed, 11 Nov 2020 09:11:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726915AbgKKRGY (ORCPT + 99 others); Wed, 11 Nov 2020 12:06:24 -0500 Received: from muru.com ([72.249.23.125]:48078 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbgKKRGX (ORCPT ); Wed, 11 Nov 2020 12:06:23 -0500 Received: from hillo.muru.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTP id 7DAF88126; Wed, 11 Nov 2020 17:06:27 +0000 (UTC) From: Tony Lindgren To: Lee Jones Cc: linux-kernel@vger.kernel.org, Carl Philipp Klemm , Laxminath Kasam , Merlijn Wajer , Mark Brown , Pavel Machek , Sebastian Reichel , Tim Harvey Subject: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack Date: Wed, 11 Nov 2020 19:06:13 +0200 Message-Id: <20201111170613.46057-1-tony@atomide.com> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With commit 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers"), the cpcap interrupts are no longer getting acked properly leading to a very unresponsive device with CPUs fully loaded spinning in the threaded IRQ handlers. To me it looks like the clear_ack commit above actually fixed a long standing bug in regmap_irq_thread() where we unconditionally acked the interrupts earlier without considering ack_invert. And the issue with cpcap started happening as we now also consider ack_invert. Tim Harvey tried to fix this issue earlier with "[PATCH v2] regmap: irq: fix ack-invert", but the reading of the ack register was considered unnecessary for just ack_invert, and we did not have clear_ack available yet. As the cpcap irqs worked both with and without ack_invert earlier because of the unconditional ack, the problem remained hidden until now. Also, looks like the earlier v3.0.8 based Motorola Android Linux kernel does clear_ack style read-clear-write with "ireg_val & ~mreg_val" instead of just ack_invert style write. So let's switch cpcap to use clear_ack to fix the issue. Fixes: 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers") Cc: Carl Philipp Klemm Cc: Laxminath Kasam Cc: Merlijn Wajer Cc: Mark Brown Cc: Pavel Machek Cc: Sebastian Reichel Cc: Tim Harvey Signed-off-by: Tony Lindgren --- drivers/mfd/motorola-cpcap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c --- a/drivers/mfd/motorola-cpcap.c +++ b/drivers/mfd/motorola-cpcap.c @@ -97,7 +97,7 @@ static struct regmap_irq_chip cpcap_irq_chip[CPCAP_NR_IRQ_CHIPS] = { .ack_base = CPCAP_REG_MI1, .mask_base = CPCAP_REG_MIM1, .use_ack = true, - .ack_invert = true, + .clear_ack = true, }, { .name = "cpcap-m2", @@ -106,7 +106,7 @@ static struct regmap_irq_chip cpcap_irq_chip[CPCAP_NR_IRQ_CHIPS] = { .ack_base = CPCAP_REG_MI2, .mask_base = CPCAP_REG_MIM2, .use_ack = true, - .ack_invert = true, + .clear_ack = true, }, { .name = "cpcap1-4", @@ -115,7 +115,7 @@ static struct regmap_irq_chip cpcap_irq_chip[CPCAP_NR_IRQ_CHIPS] = { .ack_base = CPCAP_REG_INT1, .mask_base = CPCAP_REG_INTM1, .use_ack = true, - .ack_invert = true, + .clear_ack = true, }, }; -- 2.29.2