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 E886013DDA4 for ; Fri, 8 May 2026 09:38:09 +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=1778233091; cv=none; b=rdL5MGI9yxzh9J1sYoy5S8Gu0HUaPBY1oW3zsIKFuxcJ9A3fhNjhbdSdagCQH7B0NdFveoQfAu4EmY+FuVhALrQGN6fBx+87ZL1YU3gpCmB4bcxubyJ6kd/EEnR1lSE1bpgCMvjh39T9Ec5AjvXMm1Tx6xRkWsB1EFCbbG/pUYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778233091; c=relaxed/simple; bh=VwmEXXw0tSFbY6/crtHABcMmJJSuggKfOPrbxXWUh0c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hz54ZpMo/o2TOwfVSJRJYYdtZwMhAypqyCLYc0uGmF9H580xV956FfI1xK5RSXfxKxzq7ZewQjXawvaXxAF0/FOWLgNXoWrlPL/458ej2o2nB5K3wnwZHPuAwjv9kDWGoXnCvfhjqxtFOjxWkyQ91CD0ffTlVKR0qO8On8CLBpE= 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; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=vJ2W0+4l; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="vJ2W0+4l" 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 BF62F1BCA; Fri, 8 May 2026 02:38:03 -0700 (PDT) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1390C3FAF5; Fri, 8 May 2026 02:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778233089; bh=VwmEXXw0tSFbY6/crtHABcMmJJSuggKfOPrbxXWUh0c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vJ2W0+4lrQpJAoTPpmCQDF8cSKPXZ77CfdJnTLjAhQoAarTOYomfu4Q3VyjqfpueG VdSeWGvubLNw7ezXXAr8my+7vTJupdrKEsFyZ3wRYLcihPIcKTm1Pkwuime4URrNtd gmfJOz2D4G4SQ7VwpPpXhG9RER4HrQC7zkOImV8U= Message-ID: Date: Fri, 8 May 2026 10:37:58 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH v2 2/2] arm_mpam: Update architecture version check for MPAM MSC To: Zeng Heng , James Morse , xry111@xry111.site, catalin.marinas@arm.com, maz@kernel.org, ardb@kernel.org, yang@os.amperecomputing.com, ryan.roberts@arm.com, kevin.brodsky@arm.com, reinette.chatre@intel.com, miko.lenczewski@arm.com, will@kernel.org, suzuki.poulose@arm.com, thuth@redhat.com, james.clark@linaro.org, lpieralisi@kernel.org, broonie@kernel.org, oupton@kernel.org, anshuman.khandual@arm.com, yeoreum.yun@arm.com, leo.yan@arm.com, mrigendra.chaubey@gmail.com, fenghuay@nvidia.com, ahmed.genidi@arm.com, mark.rutland@arm.com Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, wangkefeng.wang@huawei.com References: <20260203095406.6437-1-zengheng4@huawei.com> <20260203095406.6437-3-zengheng4@huawei.com> <01ef61ca-7ba7-b282-7ec6-b1df5c301aa5@huawei.com> Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi James and Zeng, On 5/8/26 04:47, Zeng Heng wrote: > Hi James, > > On 2026/5/8 10:26, Zeng Heng wrote: > >>> I think its simpler to rule out the unsupported combinations, something like: >>> | static bool mpam_msc_check_aidr(struct mpam_msc *msc) >>> | { >>> |     u32 rev; >>> | >>> |     rev = __mpam_read_reg(msc, MPAMF_AIDR) & MPAMF_AIDR_ARCH_REV; >>> | >>> |      /* >>> |      * v0.0 and >v2.x aren't supported, but anything else should be backward >>> |     * compatible to v0.1 or v1.0. >>> |     */ >>> |     if (!rev) >>> |         return false; >>> |     if (rev & MPAMF_AIDR_ARCH_MAJOR_REV > MPAM_ARCHITECTURE_V1) >>> |         return false; >>> | > > Oops, after more complete version number testing, I found there's an > operator precedence issue here. The correct fix is: > >     if ((rev & MPAMF_AIDR_ARCH_MAJOR_REV) > MPAM_ARCHITECTURE_V1) >         return false; > > Note that '>' has higher precedence than '&'. Isn't it better to use FIELD_GET()? We could also avoid creating MPAMF_AIDR_ARCH_REV and use MPAMF_AIDR_ARCH_MAJOR_REV and MPAMF_AIDR_ARCH_MINOR_REV directly to stop splitting the logic over two files. mpam_msc_check_aidr() could become: static bool mpam_msc_check_aidr(struct mpam_msc *msc) { u32 aidr = __mpam_read_reg(msc, MPAMF_AIDR); u32 major = FIELD_GET(MPAMF_AIDR_ARCH_MAJOR_REV, aidr); u32 minor = FIELD_GET(MPAMF_AIDR_ARCH_MINOR_REV, aidr); /* * v0.0 and >v2.x aren't supported, but anything else should be backward * compatible to v0.1 or v1.0. */ if (!major && !minor) return false; if (major > MPAM_ARCHITECTURE_V1) return false; return true; } Thanks, Ben > > > With this fix included: > Tested-by: Zeng Heng > > >>> |     return true; >>> | } >>> >>>> +    if (!mpam_msc_check_aidr(msc)) { >>>> +        dev_err_once(dev, "MSC does not match MPAM architecture\n"); >>>>           return -EIO; >>>>       } >>> >>> I'd like to keep the 'v1.x' in this message - this should help folk with old stable >>> kernels running on new hardware work out why the feature isn't available. >>> (assuming they have some documentation that says v2.0 in it!) >>> >>> I've rebased this with the above changes, which I'll post shortly for fixes. >>> >>> >> >> Agreed. Keep the backward compatibility extension for versions >> (compatible with v0.x(x>0) and 1.x), and remove the redundant >> MPAM_ARCHITECTURE_Vx_x macro definitions. >> >> I've verified locally that everything works fine. >> > >