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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 28 Dec 2020 13:42:41 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org, Carl Philipp Klemm <philipp@...s.xyz>,
        Laxminath Kasam <lkasam@...eaurora.org>,
        Merlijn Wajer <merlijn@...zup.org>,
        Mark Brown <broonie@...nel.org>, Pavel Machek <pavel@....cz>,
        Sebastian Reichel <sre@...nel.org>,
        Tim Harvey <tharvey@...eworks.com>,
        Tony Lindgren <tony@...mide.com>,
        Lee Jones <lee.jones@...aro.org>,
        Sasha Levin <sashal@...nel.org>
Subject: [PATCH 5.10 163/717] mfd: cpcap: Fix interrupt regression with regmap clear_ack

From: Tony Lindgren <tony@...mide.com>

[ Upstream commit 14639a22de657eabbb776f503a816594393cc935 ]

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 <tharvey@...eworks.com> 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 <philipp@...s.xyz>
Cc: Laxminath Kasam <lkasam@...eaurora.org>
Cc: Merlijn Wajer <merlijn@...zup.org>
Cc: Mark Brown <broonie@...nel.org>
Cc: Pavel Machek <pavel@....cz>
Cc: Sebastian Reichel <sre@...nel.org>
Cc: Tim Harvey <tharvey@...eworks.com>
Signed-off-by: Tony Lindgren <tony@...mide.com>
Tested-by: Pavel Machek <pavel@....cz>
Reviewed-By: Tim Harvey <tharvey@...eworks.com>
Signed-off-by: Lee Jones <lee.jones@...aro.org>
Signed-off-by: Sasha Levin <sashal@...nel.org>
---
 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
index 2283d88adcc25..30d82bfe5b02f 100644
--- 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.27.0



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ