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 8B36E86344; Fri, 17 Oct 2025 18:50:54 +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=1760727056; cv=none; b=OKMe9QwEZAyLLiQDwfiRoWIg0ND5ts/KmGe6EWM0/tQynMQph+kFEO7wbbELtUVhG3XYJQ3alcAKNeTJIoKaAkJqVe6QVG4GZOZ1/0BmX80z9EA466oyY4rcHti060sTFXAagaPQ/wSWn89lYDF4QLMq7lPA7ieHvCzh2g6nujE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760727056; c=relaxed/simple; bh=lJVsa2IA0P3lCZxqp63ZMqEf1tszgUBL+5SEzPYsMJM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FV0QlKtMOVN7iW5wB7nYR4cNDEXYlrOwZbVfSv44OKC/OIlxXf7LfcZfub7vvcan+i7yLpzYiiaqbZZO0Tj+eey6bh/zj65PYyF04wiDcKYV3rX+cnuWmUwVwU/KR6z+PJZVjRusIQGAJzRDY2U/qkApvncxyJLGHUuqjDbjOtA= 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 930301515; Fri, 17 Oct 2025 11:50:45 -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 90E0B3F6A8; Fri, 17 Oct 2025 11:50:48 -0700 (PDT) Message-ID: <72750912-ed50-4a1b-8c43-455a7bc9efc1@arm.com> Date: Fri, 17 Oct 2025 19:50:46 +0100 Precedence: bulk X-Mailing-List: linux-kernel@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: Fenghua Yu , 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 , 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> <1f084a23-7211-4291-99b6-7f5192fb9096@nvidia.com> Content-Language: en-GB From: James Morse In-Reply-To: <1f084a23-7211-4291-99b6-7f5192fb9096@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Fenghua, On 05/10/2025 21:43, Fenghua Yu wrote: > Hi, James, > > On 9/10/25 13: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. > > typo: s/dirtyied/dirtied/ > > >> >> 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. >> >> CC: Rohit Mathew >> Signed-off-by: James Morse > > Other than the minor comments, > > Reviewed-by: Fenghua Yu Thanks, > [SNIP] >> +static void mpam_reset_ris(struct mpam_msc_ris *ris) >> +{ >> +    u16 partid, partid_max; >> + >> +    mpam_assert_srcu_read_lock_held(); >> + >> +    if (ris->in_reset_state) >> +        return; >> + >> +    spin_lock(&partid_max_lock); >> +    partid_max = mpam_partid_max; >> +    spin_unlock(&partid_max_lock); >> +    for (partid = 0; partid < partid_max; partid++) > >  * Should partid_max be inclusive? So it's "partid < partid_max + 1" here? > > MPAM spec says max PARTID is inclusive: "The range of valid PARTIDs is 0 to the maximum > PARTID, inclusive. The maximum values of a PARTID implemented by different MSCs need not > be the same". Hmmm, if partid_max is 0 then this loop should run only once, so yet. Thanks, James