From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 61BE2CD3447 for ; Fri, 8 May 2026 09:56:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Cc:To:From:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=1PT66SDiP/7Gdpzm2vC7to14Cjh2IHKePKjHKrO6bLI=; b=3vebg8mcYrVBhJjblDVuxDvSmc 6CvFUn5r+A+bzepbHalKMpYkyKbKevz39KEwSCW9od4tjGgx9UPyhD7l8cUZVF/rSnlYMXdYxUuUh uuWfn14T+vcoXnfIcEzBDCrUY25JjTd2i0KsS+WUBXa7Z8MuEmmSDzgM5RqvHpZcyq2XtVxSxLEiy Upjt1XPgW6VDyqMlXWPEVJL+yj5L2cEcBCsY/zzuRR0AzG73up3N1IvnBZlJmOnJkfxdVEfmAqIEi Uz7Fk5Kh8IelsQ8E7lckRWPGgt72/qmIkPpJpPFFdMZ76GzxbUgFUy4uUp1a+wNuLOL6AZUxBiEpH MLAuyqDg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wLHwY-00000006Aeb-21Dl; Fri, 08 May 2026 09:56:26 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wLHwV-00000006Adk-2ui0 for linux-arm-kernel@lists.infradead.org; Fri, 08 May 2026 09:56:24 +0000 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 8D6771BCA; Fri, 8 May 2026 02:56:16 -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 D10773F836; Fri, 8 May 2026 02:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778234181; bh=mg+ZxMlFGeEp/e8j5ZJ9I1IfbFCj4L4MRWXURGQa2Vo=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=l9VyqxyY0RpEhlgnKwZ7v8ea1hy6h5x4zJCvjXksCqLfK33BNgpGfu+TtRmG0zuhe pDy/pTBj4Z8/OnB7LB9/BXRNoqoOD5x0BHysj2F2sNbvSarHyLipN7wDk05ZwZHWvP D7Lahz+A+9O17ppUsscH+olxlCyPzqs8KhXKrRHs= Message-ID: <7b9d69df-8086-472d-b0c3-8d46e1b5399e@arm.com> Date: Fri, 8 May 2026 10:56:17 +0100 MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH v2 2/2] arm_mpam: Update architecture version check for MPAM MSC From: Ben Horgan 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 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260508_025623_825582_406EA122 X-CRM114-Status: GOOD ( 17.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi again James and Zeng, On 5/8/26 10:37, Ben Horgan wrote: > 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) This isn't correct. I missed that MPAM_ARCHITECTURE_V1 is 0x10 (which matches MPAMF_AIDR_ARCH_REV) and not 1. Thanks, Ben > 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. >>> >> >> >