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 E1C0D2D593C; Wed, 10 Sep 2025 19:30:52 +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=1757532654; cv=none; b=FY977aQeqen8DbxhPRmorhmidWMcVLP9tQErmWJgQhc3oRe9hqMdVOATqohac5gdmR3xj+ZRBqKeqKWf3Eq3wAX31+zJ+R7l8guvPil7pnTNwjCKtWhlSLOTf/kJLCS/zb9jem+EbNhu+gR30a/6A9IvWxs8IqxRWdsgRAEccPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757532654; c=relaxed/simple; bh=pObe5aWVYV6eGcu3pJTvxDbgSxA/QkHIfWc8ZZHMS+I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=oRcJVI5beWSlcz42GtltPL3FADAy988/pForlYCc0Nv0ZaROE7apmhEfHUrt8uUSsh/fUTChHfAGVuUf/aQYjNpiJGt0x0RcHPPBdVkJiGvgpPyvgmYuRwpt0uIICOm5Qyo3ZhGTUGNkCex0O8He+wT1LDuG9yIshnaHQ1dN9jI= 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 EA46A16F2; Wed, 10 Sep 2025 12:30:43 -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 31ACF3F694; Wed, 10 Sep 2025 12:30:45 -0700 (PDT) Message-ID: <7760c082-2702-42bb-ad0d-cc7db40b0d4d@arm.com> Date: Wed, 10 Sep 2025 20:30:45 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 30/33] arm_mpam: Use long MBWU counters if supported To: Ben Horgan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org, devicetree@vger.kernel.org Cc: shameerali.kolothum.thodi@huawei.com, 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 , Rex Nie , 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 , Krzysztof Kozlowski , Conor Dooley , Catalin Marinas , Will Deacon , Greg Kroah-Hartman , Danilo Krummrich References: <20250822153048.2287-1-james.morse@arm.com> <20250822153048.2287-31-james.morse@arm.com> Content-Language: en-GB From: James Morse In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Ben, On 29/08/2025 17:39, Ben Horgan wrote: > On 8/22/25 16:30, James Morse wrote: >> From: Rohit Mathew >> >> If the 44 bit (long) or 63 bit (LWD) counters are detected on probing >> the RIS, use long/LWD counter instead of the regular 31 bit mbwu >> counter. >> >> Only 32bit accesses to the MSC are required to be supported by the >> spec, but these registers are 64bits. The lower half may overflow >> into the higher half between two 32bit reads. To avoid this, use >> a helper that reads the top half multiple times to check for overflow. > Looks good to me. > > Reviewed-by: Ben Horgan Thanks! >> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c >> index 2ab7f127baaa..8fbcf6eb946a 100644 >> --- a/drivers/resctrl/mpam_devices.c >> +++ b/drivers/resctrl/mpam_devices.c >> @@ -1058,6 +1100,7 @@ static void read_msmon_ctl_flt_vals(struct mon_read *m, u32 *ctl_val, >> static void clean_msmon_ctl_val(u32 *cur_ctl) >> { >> *cur_ctl &= ~MSMON_CFG_x_CTL_OFLOW_STATUS; >> + *cur_ctl &= ~MSMON_CFG_MBWU_CTL_OFLOW_STATUS_L; > I observe that this bit is res0, in the CSU case, and so the clearing is ok. As they've started allocating bits that collide, it probably shouldn't rely on that. The bug would be when that bit gets set for CSU in the future, its always masked out and the monitor gets reprogrammed every time. (possibly incurring the timeout each time) Changed as: | if (FIELD_GET(MSMON_CFG_x_CTL_TYPE, *cur_ctl) == MSMON_CFG_MBWU_CTL_TYPE_MBWU) | *cur_ctl &= ~MSMON_CFG_MBWU_CTL_OFLOW_STATUS_L; Thanks, James