mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Robbie King <robbiek@xsightlabs.com>,
	Huisong Li <lihuisong@huawei.com>,
	Adam Young <admiyo@os.amperecomputing.com>,
	Jassi Brar <jassisinghbrar@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	linux-acpi@vger.kernel.org
Subject: [PATCH AUTOSEL 6.14 23/23] mailbox: pcc: Always clear the platform ack interrupt first
Date: Thu,  3 Apr 2025 20:04:00 -0400	[thread overview]
Message-ID: <20250404000402.2688049-23-sashal@kernel.org> (raw)
In-Reply-To: <20250404000402.2688049-1-sashal@kernel.org>

From: Sudeep Holla <sudeep.holla@arm.com>

[ Upstream commit cf1338c0e02880cd235a4590eeb15e2039c873bc ]

The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks
for command completion flags and any error status before clearing the
interrupt.

The below sequence highlights an issue in the handling of PCC mailbox
interrupts, specifically when dealing with doorbell notifications and
acknowledgment between the OSPM and the platform where type3 and type4
channels are sharing the interrupt.

-------------------------------------------------------------------------
| T |       Platform Firmware         |    OSPM/Linux PCC driver        |
|---|---------------------------------|---------------------------------|
| 1 |                                 | Build message in shmem          |
| 2 |                                 | Ring Type3 chan doorbell        |
| 3 | Receives the doorbell interrupt |                                 |
| 4 | Process the message from OSPM   |                                 |
| 5 | Build response for the message  |                                 |
| 6 | Ring Platform ACK interrupt on  |                                 |
|   |  Type3 chan to OSPM             | Received the interrupt          |
| 7 | Build Notification in Type4 Chan|                                 |
| 8 |                                 | Start processing interrupt in   |
|   |                                 |  pcc_mbox_irq() handler         |
| 9 |                                 | Enter PCC handler for Type4 chan|
|10 |                                 | Check command complete cleared  |
|11 |                                 | Read the notification           |
|12 |                                 | Clear Platform ACK interrupt    |
|   | No effect from the previous step yet as the Platform ACK          |
|   |  interrupt has not yet been triggered for this channel            |
|13 | Ring Platform ACK interrupt on  |                                 |
|   | Type4 chan to OSPM              |                                 |
|14 |                                 | Enter PCC handler for Type3 chan|
|15 |                                 | Command complete is set.        |
|16 |                                 | Read the response.              |
|17 |                                 | Clear Platform ACK interrupt    |
|18 |                                 | Leave PCC handler for Type3     |
|19 |                                 | Leave pcc_mbox_irq() handler    |
|20 |                                 | Re-enter pcc_mbox_irq() handler |
|21 |                                 | Enter PCC handler for Type4 chan|
|22 |                                 | Leave PCC handler for Type4 chan|
|23 |                                 | Enter PCC handler for Type3 chan|
|24 |                                 | Leave PCC handler for Type3 chan|
|25 |                                 | Leave pcc_mbox_irq() handler    |
-------------------------------------------------------------------------

The key issue occurs when OSPM tries to acknowledge platform ack
interrupt for a notification which is ready to be read and processed
but the interrupt itself is not yet triggered by the platform.

This ineffective acknowledgment leads to an issue later in time where
the interrupt remains pending as we exit the interrupt handler without
clearing the platform ack interrupt as there is no pending response or
notification. The interrupt acknowledgment order is incorrect.

To resolve this issue, the platform acknowledgment interrupt should
always be cleared before processing the interrupt for any notifications
or response.

Reported-by: Robbie King <robbiek@xsightlabs.com>
Reviewed-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Adam Young <admiyo@os.amperecomputing.com>
Tested-by: Robbie King <robbiek@xsightlabs.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/mailbox/pcc.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 8fd4d0f79b090..f8215a8f656a4 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -313,6 +313,10 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
 	int ret;
 
 	pchan = chan->con_priv;
+
+	if (pcc_chan_reg_read_modify_write(&pchan->plat_irq_ack))
+		return IRQ_NONE;
+
 	if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE &&
 	    !pchan->chan_in_use)
 		return IRQ_NONE;
@@ -330,9 +334,6 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
 		return IRQ_NONE;
 	}
 
-	if (pcc_chan_reg_read_modify_write(&pchan->plat_irq_ack))
-		return IRQ_NONE;
-
 	/*
 	 * Clear this flag after updating interrupt ack register and just
 	 * before mbox_chan_received_data() which might call pcc_send_data()
-- 
2.39.5


      parent reply	other threads:[~2025-04-04  0:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04  0:03 [PATCH AUTOSEL 6.14 01/23] crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP() Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 02/23] selftests/bpf: Fix stdout race condition in traffic monitor Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 03/23] pinctrl: renesas: rza2: Fix potential NULL pointer dereference Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 04/23] pinctrl: mcp23s08: Get rid of spurious level interrupts Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 05/23] MIPS: cm: Detect CM quirks from device tree Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 06/23] crypto: ccp - Add support for PCI device 0x1134 Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 07/23] crypto: lib/Kconfig - Fix lib built-in failure when arch is modular Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 08/23] crypto: null - Use spin lock instead of mutex Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 09/23] bpf: Fix kmemleak warning for percpu hashmap Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 10/23] HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 11/23] bpf: Fix deadlock between rcu_tasks_trace and event_mutex Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 12/23] clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec() Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 13/23] parisc: PDT: Fix missing prototype warning Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 14/23] s390/sclp: Add check for get_zeroed_page() Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 15/23] s390/tty: Fix a potential memory leak bug Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 16/23] clk: renesas: rzv2h: Adjust for CPG_BUS_m_MSTOP starting from m = 1 Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 17/23] selftests/bpf: Fix cap_enable_effective() return code Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 18/23] bpf: bpftool: Setting error code in do_loader() Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 19/23] bpf: Only fails the busy counter check in bpf_cgrp_storage_get if it creates storage Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 20/23] bpf: Reject attaching fexit/fmod_ret to __noreturn functions Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 21/23] x86/Kconfig: Make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32 Sasha Levin
2025-04-04  0:03 ` [PATCH AUTOSEL 6.14 22/23] mailbox: pcc: Fix the possible race in updation of chan_in_use flag Sasha Levin
2025-04-04  0:04 ` Sasha Levin [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=20250404000402.2688049-23-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=admiyo@os.amperecomputing.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=lihuisong@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robbiek@xsightlabs.com \
    --cc=stable@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®