From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0C9FD30B532; Tue, 30 Sep 2025 17:06:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759252005; cv=none; b=fporKATdSkxMhiRlt1PQUBI2Oydh0VB1xQsB+TEbeBZO3kQpht6uU5a8dXRF9GErhA5YFulWW7bh8vYNG30o/WQMKhwiIYyMSMWWZS7ATbWgFNaOzUKQ6/oDy1xZtjA//sUIG44AUyC42H4qM0TzD5xJee9trMrX2w7dSI84ha8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759252005; c=relaxed/simple; bh=NBMaELzfZ7zcj1yTXywU1ROp7HmEQS/Qzo69z0Xz8Rs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=An/oXVszN7hxKCrKG5RFACNRfG37OliKq6MT/u6g2rdbZUys/EnGe4DqyydVYpm2aP/uoXHtkl5Xs8QO3aPPZF7SJECZGIMpeRgula0gpcYoQOPRvifYg6Yg6KcrL5/kwpVs/ljgOWzi5SSI19oxjeD0U7bKXpUfGWVlFgWrG80= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6083225E0; Tue, 30 Sep 2025 10:06:35 -0700 (PDT) Received: from [10.1.197.69] (eglon.cambridge.arm.com [10.1.197.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7E65A3F59E; Tue, 30 Sep 2025 10:06:37 -0700 (PDT) Message-ID: Date: Tue, 30 Sep 2025 18:06:26 +0100 Precedence: bulk X-Mailing-List: linux-acpi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 15/29] arm_mpam: Reset MSC controls from cpu hp callbacks To: Ben Horgan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org Cc: D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Dave Martin , Koba Ko , Shanker Donthineni , fenghuay@nvidia.com, baisheng.gao@unisoc.com, Jonathan Cameron , Rob Herring , Rohit Mathew , Rafael Wysocki , Len Brown , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Catalin Marinas , Will Deacon , Greg Kroah-Hartman , Danilo Krummrich References: <20250910204309.20751-1-james.morse@arm.com> <20250910204309.20751-16-james.morse@arm.com> <52b6bd30-55af-4916-89c0-f87446689fbe@arm.com> Content-Language: en-GB From: James Morse In-Reply-To: <52b6bd30-55af-4916-89c0-f87446689fbe@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Ben, On 12/09/2025 15:52, Ben Horgan wrote: > On 9/12/25 12:25, Ben Horgan wrote: >> Hi James, >> >> On 9/10/25 21:42, James Morse wrote: >>> When a CPU comes online, it may bring a newly accessible MSC with >>> it. Only the default partid has its value reset by hardware, and >>> even then the MSC might not have been reset since its config was >>> previously dirtyied. e.g. Kexec. >>> >>> Any in-use partid must have its configuration restored, or reset. >>> In-use partids may be held in caches and evicted later. >>> >>> MSC are also reset when CPUs are taken offline to cover cases where >>> firmware doesn't reset the MSC over reboot using UEFI, or kexec >>> where there is no firmware involvement. >>> >>> If the configuration for a RIS has not been touched since it was >>> brought online, it does not need resetting again. >>> >>> To reset, write the maximum values for all discovered controls. >>> +static void mpam_reset_msc(struct mpam_msc *msc, bool online) >>> +{ >>> + struct mpam_msc_ris *ris; >>> + >>> + mpam_assert_srcu_read_lock_held(); >> >> Unneeded? Checked in list_for_each_entry_srcu().> + > > If you do get rid of this then that leaves one use of the helper, > mpam_assert_srcu_read_lock_held(), and so the helper could go. By the end of the series, yes. But there are transiently a few more until then - they get removed and replaced with comments when those functions get called by IPI as lockdep expects the lock to be held by current, which isn't true if you IPI'd. I'll drop the helper. Thanks, James