From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=205.220.168.131 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794500097; b=jXWHiNjYRe+eEPqAFr2No2A8yXZFHuhIoxZWto1njLeRsIfiCSYBrOGcRWx3ijiclzAR jOaIJiModNqmeZn/smDz+VvR5ZO45A7qlAaj0TV89UfFW//qgxI7W8/EhOhZupIdU4IRV xGMTY8tRRndHyeNHZdiIUua+qR4e58/QqRzQSduq1ZbB/6HNdl0WMCBzpVuldRV4nCpvk o5wlUYLYtECJ9tNnrplLH7+qF63kw7czmy3L+n8EqYMWccfytm3tr88RQHnldIk5v7vng iILA3hsa6Yaw+enyPSDI+eGLNT7DrthTUn1abIXLhJNMnUPofipeTNDLR7TzO9esIAQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794500097; h=DMARC-Filter:Received:DKIM-Signature:Received:Received: DKIM-Signature:X-Google-DKIM-Signature:X-Forwarded-Encrypted: X-Gm-Message-State:X-Gm-Gg:X-Received:X-Received:Received: Mime-Version:Content-Transfer-Encoding:Content-Type:Date:Message-Id: From:Subject:Cc:To:References:In-Reply-To:X-Proofpoint-Spam-Info: X-Proofpoint-GUID:X-Proofpoint-ORIG-GUID: X-Proofpoint-Spam-Details-Enc:X-Authority-Analysis: X-Proofpoint-Virus-Version:X-Proofpoint-Spam-Details; bh=VFyW3FlcFVuCcTw1UrnIFaWy9gAZYFzgF43VrM5oqOQ=; b=v61SpcXt6hH/ZT9Nf3S77jYo1jpE2bppNLX8ziomJ6H9qfIe8bOx1ji357S8rfVTai3R ePg9+TakPqT6a8NrZcAUh0lvyQbEM/MxD6OMrF8vEcU83k//ZTYampgIfqVuCN4pS3EDU ATNH7pTqUM7xh4Pa9/Bf1ifMCdoYuDpA3lEvCyLv2XeNqm+YppDKmnhIzTbR0g5hMvse9 9bh3GgRpfAObEkVMJjpHn5CVv8/KHW/0sRalC/MM67+ojAR9jggI5LJn9vvetmXzn7uJ5 Np6b8yGix1BaR6oL07Y/XMMb02a5kbYyG9p9Zo+vkNGeXsvmiARARijVpP/su+pq/pw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256 header.s=qcppdkim1 header.b=KMK6QB0C; dkim=pass header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.a=rsa-sha256 header.s=google header.b=MwZumgfo; arc=none smtp.remote-ip=205.220.168.131 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D077A606A32A for ; Thu, 12 Nov 2026 16:14:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org D077A606A32A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.a=rsa-sha256 header.s=qcppdkim1 header.b=KMK6QB0C; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.a=rsa-sha256 header.s=google header.b=MwZumgfo Received: from pps.filterd (m0279863.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 6ACFaNqM1593451 for ; Thu, 12 Nov 2026 16:14:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= VFyW3FlcFVuCcTw1UrnIFaWy9gAZYFzgF43VrM5oqOQ=; b=KMK6QB0C53FsJS4C tFzPmI8KYZXPG9YLJzFIHsq2h7uTULHaITsbeYFUIXrtAyTo9VDxZNrFSqDkzJpq mC8m8R/fymWFTkZR+zYJufGcFbmWp/MxWX76MlvAFLbG9FoP2f+z+rKCIxe+RYZp fNg29Szh9iFitCyIbL9cy/C2Vl7m85c3g6TI51EIbHfLC9h8O0jJ6fgHrtpY4rGL 08kayBMDGukcYg/QNo/plpZ072zNL/DySCmPjrKsTCznHdBeN8UXVE0looqITHXV CSjb2q9owW+uO5CsIU7QdGzYYy2A7CSYd9P6FRWnSeZKPdrXY2GcO5p65ofbSXCx kI4SBw== Received: from mail-ua1-f71.google.com (mail-ua1-f71.google.com [209.85.222.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4hw0m8knaj-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 12 Nov 2026 16:14:56 +0000 (GMT) Received: by mail-ua1-f71.google.com with SMTP id a1e0cc1a2514c-99c3b473613so9018241.1 for ; Thu, 12 Nov 2026 08:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1794500095; x=1795104895; darn=vger.kernel.org; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-type:content-transfer-encoding:mime-version:from:to:cc :subject:date:message-id:reply-to:content-type; bh=VFyW3FlcFVuCcTw1UrnIFaWy9gAZYFzgF43VrM5oqOQ=; b=MwZumgfoEOm5d26AKGeVF65ngzTwLKH5CVc8lCagWrkvFp+Laj1xFDiVulfoZ6aP6M 2bMP/gM3aFt/xrqyyrxmIaPowRezw+WFEg1Xj2rAtLAT5oYWhShXy01Hy4Q0hO57amq1 9Pm/1P1gME8FlVN3D0CwElj/dFC4Ts8OeSginsjNlPOm6dBJXBpM9PkQqQF0KPw+y2u0 tMnVJTK92rVjYrvtz8+6yrT9ErXXNdjiiPO2zOQx1dcqTeUvuE7CbXdbzir8PC82RRLM w6zLnI0Ryk3lRoUKHTh38BdOX+GyjqUg4wAaUbMMyYc8XLQiXkM6jO+CbLw54WRyBkD4 gIQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794500095; x=1795104895; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-type:content-transfer-encoding:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=VFyW3FlcFVuCcTw1UrnIFaWy9gAZYFzgF43VrM5oqOQ=; b=BheEG+1+Kmi7pONe8GKertzXQKBUrDi8SP2DZADPn2twVokj3tO1gFDfh463H2kyyS LNbRqR8T0MS2YhZKAaE9h+uN8yNWWtDtiWq4ANZtEmQtpYvuVr7qAfnotV9TDMoFcp89 Jn4P0wmpEjKh6pVt1fMSc891MeZ2PhtFDVn5n1TCjzVHk3toyl2eTbm/NAsKTdvD113s g0o3EpGmitItLw9Tny86bsQ2CQ7dDo35DNp2ywvvL0yTxsCf3praIMvFzyBEGZ9FsnaM vTw7T8w4KqDyL7tIU2TTIIAwSt4lEEuJ4bMKrPC3WCUq++8FXBA5Fe1IB3Nar9ydIxLG 8rVw== X-Forwarded-Encrypted: i=1; AL+hErH+KfGEET3sRXYZlq7hUAWZ2sexm3anwVPOQSqQptVnHN6A7PiMqcaUa+hMZNevZ+XEVfXY/Z1sgok=@vger.kernel.org X-Gm-Message-State: APuU4Z8rBn/6dE1DIWJhhm+JSlivGnsmo0WbMCa2Au8H9OpMfgTvTeb+ RjjLbghG0icFxbmiK8Pd4nOHQI8JA37Wp/j62crhhprmzXRSLkOo3Q+bOEeBWLVKuRQ500cLG7e Y5roSX65Cu1mNrxlnVG/wEeXXpURRbYBcOwo10vHN0tOnnR4TSG6hO5SME9MKIhQ= X-Gm-Gg: AYBFou091VfertbiYmwigIXANaGgxHOqdJ+WGeNqfiE34Pj3SESLHRqKW46nD66P/tU tzF11utnED9IX6k6/8r0MWwI7X3cH32ArhIRiS40VdhjMqHHVng3wkZ7bo8CdR3Z6bvweA+T7cl ksRAliWUbr2Ppeewl4XbczmL3ZN87ZVi2ENwkp5xeWjJ7+akDe04EvIBMMawyHLBGWWb61Qm/ZQ R1h7yfqvC/QaFriG+Aa2uTYocyqVzRe+TFGy2FyiswGkiFeqjKU4/g8KqZ/YwtOIT7l5lmt4WQO GamsdGI+hnQAR9rB9NONcQVGMlCM3mPseAkAhnfSpEhtjzgWFMvHiXTUCZXNoEYUIHTo0LSpc59 spF/2ij5ThePesA5J2zo+BNaoySdSEHFU/BZFQVjEmo3QkH2m2mOZAC/cNGcCQ5+2TVeMO/yQ5u Y7xwofRjTVCEk= X-Received: by 2002:a67:e109:0:b0:7ae:c2ca:8e1 with SMTP id ada2fe7eead31-7d4fb25077cmr1920113137.11.1794500094871; Thu, 12 Nov 2026 08:14:54 -0800 (PST) X-Received: by 2002:a67:e109:0:b0:7ae:c2ca:8e1 with SMTP id ada2fe7eead31-7d4fb25077cmr1920099137.11.1794500094134; Thu, 12 Nov 2026 08:14:54 -0800 (PST) Received: from localhost (ip-86-49-245-11.bb.vodafone.cz. [86.49.245.11]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4bb4e2842e6sm78783665e9.4.2026.11.12.08.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2026 08:14:53 -0800 (PST) X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 12 Nov 2026 17:14:50 +0100 Message-Id: From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= Subject: Re: [PATCH v11 1/5] riscv_cbqri: Add capacity controller core Cc: "Catalin Marinas" , "Jonathan Cameron" , "Shaopeng Tan" , "Zeng Heng" , , , , , To: "Drew Fustini" , "Adrien Ricciardi" , "Alexandre Ghiti" , "Albert Ou" , "Atish Patra" , "Babu Moger" , "Ben Horgan" , "Borislav Petkov" , "Chen Pei" , "Conor Dooley" , "Conor Dooley" , "Dave Hansen" , "Dave Martin" , "Fenghua Yu" , "Gong Shuai" , "Gong Shuai" , , "James Morse" , =?utf-8?q?Kornel_Dul=C4=99ba?= , "Krzysztof Kozlowski" , , "Liu Zhiwei" , "Palmer Dabbelt" , "Paul Walmsley" , "Peter Newman" , "Reinette Chatre" , "Rob Herring" , "Samuel Holland" , "Sunil V L" , "Tony Luck" , "Weiwei Li" , "yunhui cui" , "Zhanpeng Zhang" References: <20261108-dfustini-atl-sc-cbqri-dt-v11-0-33a1bf0cf01c@kernel.org> <20261108-dfustini-atl-sc-cbqri-dt-v11-1-33a1bf0cf01c@kernel.org> In-Reply-To: <20261108-dfustini-atl-sc-cbqri-dt-v11-1-33a1bf0cf01c@kernel.org> X-Proofpoint-Spam-Info: AW1haW4tMjYxMTEyMDA2NCBTYWx0ZWRfX5OzuEvNoQlRU b+V9S4mEpo1QFqCS0AAmX5Pi3S427CoeeuGp8PMSHkJxafOxy043VUYiJ02yPOzLMkVHLTpd/D/ OuSgMI884nNetm5jalGGpNGEdZwrp6c= X-Proofpoint-GUID: zQlT52MhThQQmN-5gijy5lerpaJz3pq1 X-Proofpoint-ORIG-GUID: zQlT52MhThQQmN-5gijy5lerpaJz3pq1 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMTEyMDA2NCBTYWx0ZWRfX96e1QjoJSLMU H+zr8AE/8O1pB5gy26UdFf+KNj7+g5DanXPFwFx/zv5fkay2k45PSvxhmaZjmTz4zHnFcvF7TWr DrPkQe+PC5ggOG6Tc0Zj+svvEnYd4itWsCznc/u2xCIW53Khez7xblqdjhJJJQ/JvIWPg8QPNqC IFaTBxX1D0aWRj0/92p21P//9xF65wlbcESCrrCreUimnhaD6BBDAknIR94vG1VMIJyqx/qGUNR LpAy70BASMyM+/4rwCYb3k51uhgpDRWTi3slGMqNGfeMCw7WihQr8Cg2PYvfmGUc8mLAa4Bt3LQ t7Ds0/+CX/hJRXsolr/MrrEjXaxH9k1Wu8mJg1oDoIp2MNNVHhUFSFbMkctD8cj1Y/nEykIwc+a i2JLabkEe9f5s6uQ81h1vGgoSMzH8YQquZNnq8JGltiRoHBktzPHioXb5/GWPa11PbMcax3dgpp 7wCj04aspcIk0aJ+T2g== X-Authority-Analysis: v=2.4 cv=Q9dHcI2a c=1 sm=1 tr=0 ts=6af5e600 cx=c_pps a=KB4UBwrhAZV1kjiGHFQexw==:117 a=4CXLxsOAgPM/krjtHEZQyA==:17 a=IkcTkHD0fZMA:10 a=zJRp6_cAMcgA:10 a=M51BFTxLslgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=yOCtJkima9RkubShWh1s:22 a=VwQbUJbxAAAA:8 a=IpJZQVW2AAAA:8 a=MPNzcpqd3dBX2N5RN88A:9 a=QEXdDO2ut3YA:10 a=o1xkdb1NAhiiM49bd1HK:22 a=IawgGOuG5U0WyFbmm1f5:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-11-12_02,2026-11-11_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 impostorscore=0 adultscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 spamscore=0 clxscore=1011 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2611040001 definitions=main-2611120064 2026-11-08T15:20:50-08:00, Drew Fustini : > Add the core for RISC-V CBQRI capacity controllers: the register > layout, the capability probe, and the allocation operations that > program a capacity block mask for an RCID and read it back. > > A discovery layer maps the register block and describes the controller > in a cbqri_controller_info descriptor. riscv_cbqri_register_cc() probes > the controller from that descriptor and adds it to the controller list, > which stays private to the core. The core owns the controller state > after registration, so nothing in it depends on how the controller was > discovered. The caller keeps the register mapping alive. > > Co-developed-by: Adrien Ricciardi > Signed-off-by: Adrien Ricciardi > Signed-off-by: Drew Fustini > --- > diff --git a/drivers/resctrl/cbqri_devices.c b/drivers/resctrl/cbqri_devi= ces.c > +static u64 cbqri_readq(void __iomem *addr) > +{ > + return lo_hi_readq(addr); > +} > + > +static void cbqri_clear_cunits(struct cbqri_controller *ctrl) > +{ > + if (ctrl->cc.cunits) { > + writel(0, ctrl->base + CBQRI_CC_CUNITS_OFF); > + writel(0, ctrl->base + CBQRI_CC_CUNITS_OFF + 4); nit: lo_hi_writeq? > +int cbqri_apply_cache_config(struct cbqri_controller *ctrl, u32 closid, > + const struct cbqri_cc_config *cfg) > +{ > [...] > + mutex_lock(&ctrl->lock); > [...] > +out: > + mutex_unlock(&ctrl->lock); > + return err; nit: guard the mutex? > +static int cbqri_probe_feature(struct cbqri_controller *ctrl, int reg_of= fset, > + int operation, int *status, bool *access_type_supported) > +{ > + const u64 active_mask =3D CBQRI_CONTROL_REGISTERS_OP_MASK | > + CBQRI_CONTROL_REGISTERS_AT_MASK | > + CBQRI_CONTROL_REGISTERS_RCID_MASK; > + u64 reg, saved_reg; > + int at; > + > + /* > + * Default the output to false so the status=3D=3D0 (feature not > + * implemented) path returns a deterministic value to the caller > + * rather than leaving an uninitialized bool. > + */ > + *access_type_supported =3D false; > + > + /* Keep the initial register value to preserve the WPRI fields */ > + reg =3D cbqri_readq(ctrl->base + reg_offset); > + saved_reg =3D reg; > + > + /* Drain any in-flight firmware op before issuing our own write. */ > + if (cbqri_wait_busy_flag(ctrl, reg_offset, &saved_reg) < 0) { > + pr_err("BUSY timeout before probe operation\n"); > + return -EIO; > + } > + > + /* > + * Execute the requested operation with all active fields > + * (OP/AT/RCID) zeroed except OP itself. Every bit not in > + * active_mask is WPRI and gets carried over from saved_reg. > + */ > + reg =3D (saved_reg & ~active_mask) | > + FIELD_PREP(CBQRI_CONTROL_REGISTERS_OP_MASK, operation); > + writel(lower_32_bits(reg), ctrl->base + reg_offset); > + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) { > + pr_err_ratelimited("BUSY timeout during operation\n"); > + return -EIO; > + } > + > + /* Get the operation status */ > + *status =3D FIELD_GET(CBQRI_CONTROL_REGISTERS_STATUS_MASK, reg); > + > + /* > + * Check for AT support if the register is implemented > + * (if not, the status value will remain 0) > + */ > + if (*status !=3D 0) { > + /* > + * Re-issue operation with AT=3DCODE so the controller > + * latches AT=3DCODE on supported hardware (or resets it to 0 > + * on hardware that doesn't). OP must be a defined CBQRI op > + * here. OP=3D0 is a no-op and would silently disable CDP. OP=3D0 is a reserved for future standard use. (Hopefully just fails, but it could be worse if it gets implemented as something other than no-op.) > + */ > + reg =3D (saved_reg & ~active_mask) | > + FIELD_PREP(CBQRI_CONTROL_REGISTERS_OP_MASK, operation) | > + FIELD_PREP(CBQRI_CONTROL_REGISTERS_AT_MASK, > + CBQRI_CONTROL_REGISTERS_AT_CODE); > + writel(lower_32_bits(reg), ctrl->base + reg_offset); > + if (cbqri_wait_busy_flag(ctrl, reg_offset, ®) < 0) { > + pr_err("BUSY timeout setting AT field\n"); > + return -EIO; > + } > + > + /* > + * If the AT field value has been reset to zero, > + * then AT support is not present > + */ > + at =3D FIELD_GET(CBQRI_CONTROL_REGISTERS_AT_MASK, reg); I think it would be safer to also check the status field. I'm not too clear whether the spec actually allows returning 5 (invalid AT) when the AT is invalid, but an implementation that does that wouldn't surprise me. (For example when an implementation supports data AT and a custom AT, so code AT isn't supported, but AT in general is -- it could keep the failing code AT and just report the error.) > + if (at =3D=3D CBQRI_CONTROL_REGISTERS_AT_CODE) > + *access_type_supported =3D true; > + } > + > + /* > + * Restore the original register value. > + * Clear OP to avoid re-triggering the probe op. > + */ > + saved_reg &=3D ~CBQRI_CONTROL_REGISTERS_OP_MASK; > + writel(lower_32_bits(saved_reg), ctrl->base + reg_offset); It would be better to do nothing than trigger an illegal OP. All our writes should modify the non-WPRI bits anyway, so restoring them does nothing. > + if (cbqri_wait_busy_flag(ctrl, reg_offset, NULL) < 0) { > + pr_err("BUSY timeout restoring register value\n"); > + return -EIO; > + } > + > + return 0; > +} > + > +static int cbqri_probe_cc(struct cbqri_controller *ctrl) > +{ > [...] > + > + /* > + * The driver programs the v1.0 register layout. Controllers that > + * report 0.x differ only in capability bits that read as zero, so > + * they are accepted. Anything newer than 1.0 may move fields. > + */ > + if (ver_major > 1 || (ver_major =3D=3D 1 && ver_minor > 0)) { I think we could accept ver_major =3D=3D 1 even with ver_minor > 0 since th= e minor specifications shouldn't be doing backward-incompatible changes. (If we fix the OP=3D0, we shouldn't be invoking any other behavior that might change.) I'd be more careful about accepting anything pre-1.0, since I would expect there was a breaking change in the spec somewhere, and we could program it incorrectly... Do we even care about pre-1.0 hardware? > + pr_warn("CC at %pa reports CBQRI version %d.%d, skipping\n", > + &ctrl->addr, ver_major, ver_minor); > + return -ENODEV; > + } Thanks.