From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B10B2D5A19 for ; Thu, 23 Jul 2026 23:18:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784848692; cv=none; b=fPAbqleq77zHk940MJPLlrUjOdxiagudRQw3V/c9qSmAIc8ie9oXm1P16tS+P1Hr206o0nEGGypVDzEK8cjUSeC9mG/vfwJ9Z9MJS1wadOkRkrhg9VE6YZO4etwyM++0caaS2d5nigKZmPDQ1SQPwbSatySdnEMNq7mXsojJhis= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784848692; c=relaxed/simple; bh=mRG5Q+bwQhOzc15TQoW9Na6Dx5/kSC1Qx5InPpubl+4=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=tAgCzMq8AmpjEAQBZmGdp64rYHmnfNUqk7+KDH+nb9k+mTPJ9pbqbZVN298+RyheVmIRMvVEEcE/3eR9jKEYDksDYuLn8qRveFqd4dUHVXcVPoXITNnHz6wCmU0HlDwWj7R4roEfsIBXRu+9Fe1w/C1p7X9KvgNtDMigaNoTdyQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=iSocWxD7; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=FJM5m7js; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject 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.b="iSocWxD7"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="FJM5m7js" Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66NLeFOX1055187 for ; Thu, 23 Jul 2026 23:18:09 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= URwVbTebyfSy3AMrazlDDmd7TkYbOHWRp0q3gMoMwL8=; b=iSocWxD79Zots23c aYAOi/YNyB9YR2O9/mB66N0pE6LU8scaLWfVmdQdOm0L/mMLKYgVdgZ7TPAquahd xSREW35SRWo1konP3esBYW7UmK3yJzPmQczhJGdhmwTtdi2M3h/VGaZ5xnkmw+kk BPKPOkpbli5KGvjKToUYWfeUJOG5fet5E5jNJCxvnDT10WS+R6Hg2sglCripMHpH /4nbJrsvyMPkLvilUytL7XdIsz3p03k/qcG66MAH8baRNfl43e/Ut1ZTPFXpOg+C P6/CCRLadbT7d+GqkAtMRowzAF3YKd6cENmAC8FyCxlxgA0tpBeVafQJ0EUGWnYg oNm3sg== Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fknbmhxhr-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 23 Jul 2026 23:18:09 +0000 (GMT) Received: by mail-pg1-f198.google.com with SMTP id 41be03b00d2f7-c9c26587e67so999701a12.0 for ; Thu, 23 Jul 2026 16:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784848688; x=1785453488; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=URwVbTebyfSy3AMrazlDDmd7TkYbOHWRp0q3gMoMwL8=; b=FJM5m7jsvwcnZS27eZJK04TdwzOcz4JAaIrXaxbPMrqbpa3TbCqb9u2/1yT0cxpxNQ pNz4OFMbxV71uhutqiKv8J49GVI0LGqbTPpiP4AqcXjEIJmKMDceKS7RjYZ9+7pC3hHV Nu2NwecsC65r58eL10GovDmtbaKJShqyWeMbS4Eur3JelHInRbSxOyp8gxR0fc28SfHw H+ybzaBBrlDywf3G8O1/G0AYqUMpPZkcX1foKaevRYSX0PUgrekdGp5gDQLXSorFRbbV /f5hXoZZoxbohYZjhNoEMTZWY4No48LDaHIh5FGStxqyW66TPwq4j+YpcRYNY5eP00tE uFCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784848688; x=1785453488; h=content-transfer-encoding:content-type:in-reply-to:content-language :references:cc:to:from:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=URwVbTebyfSy3AMrazlDDmd7TkYbOHWRp0q3gMoMwL8=; b=P7HfCwrhmk2MY4yMoqpGzCElE9rsfeQt4GQLQQgjnqJiuqn8GLEbzyaUiwfkxliYNd RH9ukUXdQeSCWf5vjbp+5PxmCH3OH8+b3WKQ2WFt80SWxKTzLIZYa0LVFzmp4SpgwCaT 7Gk5Xxmobpalfxk+1s6fe5DlOkRhXm9mVouBgd02KF1g+IctVo+e7nALFeJxSOaIFRLq nDWl7kVC+dTSkw5InopzW9eYlvPQeI0S4NK+2BRkKIOpz/DH4xvuSJL2JmWHNg9/hUzx OkARu/J5h7WrihMp6bfDiUPaDcmm/OzxScAnQJzNHUzQlr5ZYN9kaPsmfWAk/LLnCGHr X4Hg== X-Forwarded-Encrypted: i=1; AHgh+Rp0hKQLSApkZrLOvvAIvzc5MZEiZgBC+VxZ+Ff3ckMiOX1PbdPPObSoqWGkcfTqD7h839uqQAfUKGOvxoA=@vger.kernel.org X-Gm-Message-State: AOJu0Yy8ppu4moycbe1wu0+hiFB4svFTD0jbyYbzq5Cl2WGhpdD/3Rhd 71eWMwrLzbWKummBSeL+2QFh2cQsiA2Gu8KV6fX3+fVwL1UqpF73mToQjBrof7GZKTWCP7WCUYM +xxBszKiqJgSatkZOptNW5aUc5IOaPK5rlBVMI9P48YJy9VN/YSosKB26MUqwegVt4xUK8pH9m4 E= X-Gm-Gg: AR+sD13THu1plQnRj51YN1uvKdWYzimyQ7mZCDx3+tg5HKzaL/R1iE/KXQMEsFPkNrb fAduZynnvc8BbmsqoNqKS7HSRHkOQbyGxkUvhWoXnJpOhywJ4AiG+ZuaZVAgRx2ZEks2mXtx2Jp fUOjvaghHzX/mWnzQb1hU7zLdMDdBJ8nGeEoDjjmIgCkITznftEp957J1fhJPp3NzWj0D/cJUS8 auQHEfOq6PyT4ceR/PzIrLUozhMpGAAQBOL4Jw6vUz+trx5qqCk8nEWM6IwzMzgZ4xfxZMnPnGW dib229ANqHAPi7u6z8dvGEzh/NyU0ouEBcAa/SPNgGEIowzsNK8tqjjOUmlbkXvKLuaj0CRtM49 YHqPc/k4qLscs9xfRQA3ZWepyFSIW9xsQgF7ctyzbn6SAnOkgUPjBNCqO X-Received: by 2002:a05:6a21:2d43:b0:3c3:6e84:ace8 with SMTP id adf61e73a8af0-3c44caf0a32mr5366469637.23.1784848688149; Thu, 23 Jul 2026 16:18:08 -0700 (PDT) X-Received: by 2002:a05:6a21:2d43:b0:3c3:6e84:ace8 with SMTP id adf61e73a8af0-3c44caf0a32mr5366438637.23.1784848687639; Thu, 23 Jul 2026 16:18:07 -0700 (PDT) Received: from [10.71.178.173] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3147dc1a6adsm22456214eec.6.2026.07.23.16.18.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2026 16:18:06 -0700 (PDT) Message-ID: <41540b44-8142-4b80-b876-0ff3f7ddd619@oss.qualcomm.com> Date: Thu, 23 Jul 2026 16:18:06 -0700 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] cxl/hdm: Enforce CFMWS memory type policy at decoder commit time From: Mayank Rana To: Dave Jiang , linux-cxl@vger.kernel.org Cc: dan.j.williams@intel.com, ira.weiny@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com, linux-kernel@vger.kernel.org References: <20260711003341.2602368-1-mayank.rana@oss.qualcomm.com> <61531e60-0171-4d7e-b61b-ac0790a38ede@intel.com> <115d2157-d4d2-4897-a9c8-fe42fec0bbf9@oss.qualcomm.com> Content-Language: en-US In-Reply-To: <115d2157-d4d2-4897-a9c8-fe42fec0bbf9@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Authority-Analysis: v=2.4 cv=e742j6p/ c=1 sm=1 tr=0 ts=6a62a131 cx=c_pps a=Qgeoaf8Lrialg5Z894R3/Q==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=rJkE3RaqiGZ5pbrm-msn:22 a=EUspDBNiAAAA:8 a=OvxQIU2IL3wE2Do5ZK0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=x9snwWr2DeNwDh03kgHS:22 X-Proofpoint-ORIG-GUID: 5WhPnhv866DGjsuYlL6OEKTleKA8kf6J X-Proofpoint-GUID: 5WhPnhv866DGjsuYlL6OEKTleKA8kf6J X-Proofpoint-Spam-Info: AW1haW4tMjYwNzIzMDIyNSBTYWx0ZWRfX10OpHO3nwkqE xJvl/RVXgWIEA+oNlOQUeB7mfSXq4EnpnlzLJTodFAWMmj9lZmeIAGjhHISxtSQLCBuJaloPe1a 2L94gfkb/RNNflVynBz+yRem3zWCr6A= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzIzMDIyNSBTYWx0ZWRfXzcVAPaKg3ffi kaqhX6Y5L116Lh5dvWVZmlYBtJDD0gU4q1dlPMObeht4wUjG0cusw2/9BLlZIgR6GuAzDHoJKyn eycB5XOAv0nU9WjoUb001h7VVNMcgiIKmevDlZyWo2D2908mzSeJoY0u+u71v0UhIxfdCR6zlgI pn8wuO+NE4c+YERcF0CJPCyr1kWeYlcce9hLQhBBBeD0NN0iA7yprH+znNl78cm774MKeQyzGul XTTrn0v3Ii+q5PItwyA9TcOH7GqQcSvLAMG/qveO+00aDv5lKgewUyQzOa+UF/+jAlt25Kzis2h vPeaGTMgVGAXwEJLxk5tydj/sKG7SetiujxvKQLmumBX2zc0h64jVmbrj6m+ZL+W8hIzLejQrw6 LBfNtjhhyjkBXRMQWanR4dkmXUCCSDs6dY+97poO9Lq34/MK0sNlkgi0dnkTn0nzMNcac1cHSrE h+JY4fXw51dDbvaEIyA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-23_07,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607230225 Hi Dave On 7/15/2026 3:26 PM, Mayank Rana wrote: > Hi Dave > > Thank you for review comments. > > On 7/13/2026 8:47 AM, Dave Jiang wrote: >> >> >> On 7/10/26 5:33 PM, Mayank Rana wrote: >>> A CXL Fixed Memory Window Structure (CFMWS) in the ACPI CEDT table >>> carries a restrictions field that describes the memory types a platform >>> window supports.  cfmws_to_decoder_flags() translates this into >>> CXL_DECODER_F_TYPE2 (HDM-DB permitted) and CXL_DECODER_F_TYPE3 (HDM-H >>> permitted) flags on the root decoder. >>> >>> However, nothing currently prevents a caller from committing an endpoint >>> or switch decoder whose target_type conflicts with the CFMWS policy: >>> >>>    - A decoder with target_type == CXL_DECODER_DEVMEM (HDM-DB) can be >>>      committed on a window that lacks CXL_DECODER_F_TYPE2 (HDM-H only). >>>      A dual-capable device will accept HOSTONLY=0 + COMMIT=1 without >>>      asserting COMMIT_ERROR, silently violating platform policy. >>> >>>    - Symmetrically, a decoder with target_type == >>> CXL_DECODER_HOSTONLYMEM >>>      (HDM-H) can be committed on a window that lacks CXL_DECODER_F_TYPE3 >>>      (HDM-DB only), again violating ACPI CFMWS restrictions. >>> >>> Add a check in cxl_decoder_commit() that walks from the decoder's >>> assigned region to the root decoder and rejects the commit with >>> -EOPNOTSUPP if the decoder's target_type requires a capability flag that >>> the CFMWS window does not advertise: >>> >>>    - CXL_DECODER_DEVMEM      requires CXL_DECODER_F_TYPE2 on root >>> decoder >>>    - CXL_DECODER_HOSTONLYMEM requires CXL_DECODER_F_TYPE3 on the root >>>      decoder >>> >>> required_flag is initialized to zero so that any future target_type >>> values not covered by the if/else-if chain leave the enforcement check >>> a no-op via the leading required_flag && guard. >>> >>> This makes the CFMWS restrictions field authoritative for memory type >>> enforcement in both directions, regardless of individual device >>> capability. >>> The existing COMMIT_ERROR path in cxld_await_commit() remains as a >>> secondary safeguard for devices that cannot support the requested mode. >> >> Can you please trim the commit log? The AI generated verbiage is >> excessively wordy. A simple and more to the point short log that >> conveys all the information would be appreciated. > ok. noted down. >>> >>> Fixes: 3e23d17ce198 ("cxl/acpi: Use the ACPI CFMWS to create static >>> decoder objects") >>> Assisted-by: Claude:claude-sonnet-4-6 >>> Signed-off-by: Mayank Rana >>> --- >>>    - Initialize required_flag = 0 and use explicit else-if for >>>      CXL_DECODER_HOSTONLYMEM; guard enforcement with required_flag && >>>      so unknown target_type values skip the check cleanly >>> >>> Changes in v2: >>>    - Extend enforcement to cover both directions: HDM-H commits on >>>      HDM-DB-only windows are now rejected in addition to HDM-DB commits >>>      on HDM-H-only windows (reported by Sashiko AI review) >>>    - Generalize condition from single DEVMEM check to type-dispatch >>>      selecting required_flag based on target_type >>>    - Update commit message and subject to reflect bidirectional policy >>> >>> Testing >>> ------- >>> >>> The bug and fix were validated using QEMU with a modified CXL >>> configuration. >>> >>> Two test-only changes were applied (not part of this patch): >>> >>>    1. QEMU ACPI (hw/acpi/cxl.c): CFMWS restrictions field changed from >>>       0x0f to 0x02 (ACPI_CEDT_CFMWS_RESTRICT_HOSTONLYMEM only, without >>>       RESTRICT_DEVMEM).  This causes cfmws_to_decoder_flags() to set >>>       CXL_DECODER_F_TYPE3 only on the root decoder, simulating a >>> platform >>>       that does not permit HDM-DB. >>> >>>    2. Kernel (drivers/cxl/core/hdm.c): init_hdm_decoder() uncommitted >>>       endpoint path changed to force CXL_DECODER_DEVMEM unconditionally, >>>       simulating a dual-capable device (supports both HDM-H and HDM-DB). >>>       QEMU's cxl-type3 device reports CXL_DEVTYPE_CLASSMEM and defaults >>>       to HOSTONLYMEM; this override exercises the DEVMEM commit path >>> that >>>       a real Type-2 or dual-capable Type-3 device would trigger. >>> >>> Bug reproduction (without this patch): >>> >>>    # cxl create-region -m mem0 -d decoder0.0 -t pmem >>>    created 1 region >>> >>>    HDM-DB committed silently despite CFMWS advertising HDM-H only. >>>    No error or warning in dmesg. >>> >>> Fix validation (with this patch): >>> >>>    # cxl create-region -m mem0 -d decoder0.0 -t pmem >>>    cxl region: cmd_create_region: created 0 regions >>> >>>    dmesg: >>>      cxl_core: cxl region0: mem0:decoder2.0 type mismatch: 2 vs 3 >>>      cxl_port endpoint2: failed to attach decoder2.0 to region0: -6 >>> >>>    The decoder's target_type (2=DEVMEM) mismatches the region's required >>>    type (3=HOSTONLYMEM) enforced by the CFMWS restriction -- commit >>> blocked. >>> >>> QEMU invocation: >>> >>>    qemu-system-x86_64 \ >>>      -kernel bzImage \ >>>      -append "root=/dev/sda rw console=ttyS0" \ >>>      -drive file=rootfs.img,index=0,media=disk,format=raw \ >>>      -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \ >>>      -object memory-backend-file,id=cxl-mem1,share=on,mem-path=/tmp/ >>> cxltest.raw,size=256M \ >>>      -object memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/ >>> lsa.raw,size=256M \ >>>      -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ >>>      -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ >>>      -device cxl-type3,bus=root_port13,persistent-memdev=cxl- >>> mem1,lsa=cxl-lsa1,id=cxl-pmem0,sn=0x1 \ >>>      -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G \ >>>      -nographic >>> >>> >>> drivers/cxl/core/hdm.c | 29 +++++++++++++++++++++++++++++ >>>   1 file changed, 29 insertions(+) >>> >>> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c >>> index 0c80b76a5f9b..127a187cdadb 100644 >>> --- a/drivers/cxl/core/hdm.c >>> +++ b/drivers/cxl/core/hdm.c >>> @@ -802,6 +802,7 @@ static int cxl_decoder_commit(struct cxl_decoder >>> *cxld) >>>       struct cxl_port *port = to_cxl_port(cxld->dev.parent); >>>       struct cxl_hdm *cxlhdm = dev_get_drvdata(&port->dev); >>>       void __iomem *hdm = cxlhdm->regs.hdm_decoder; >>> +    struct cxl_root_decoder *cxlrd; >>>       int id = cxld->id, rc; >>>       if (cxld->flags & CXL_DECODER_F_ENABLE) >>> @@ -834,6 +835,34 @@ static int cxl_decoder_commit(struct cxl_decoder >>> *cxld) >>>           } >>>       } >>> +    /* >>> +     * Enforce CFMWS memory type policy: reject commits where the >>> decoder >>> +     * target_type conflicts with the root decoder's CFMWS >>> restrictions. >>> +     * - HDM-DB (DEVMEM) requires CXL_DECODER_F_TYPE2 on the root >>> decoder. >>> +     * - HDM-H (HOSTONLYMEM) requires CXL_DECODER_F_TYPE3 on the >>> root decoder. >>> +     * - Unknown target_type values leave required_flag zero; skip >>> enforcement. >>> +     */ >>> +    if (cxld->region) { >> >> I don't think we should gate the check based on whether cxld->region >> is valid or not. Can you please take a look at core/ >> region.c:271:cxl_region_decode_reset() and do something similar to >> acquire the root decoder by walking up the port hierachy? That should >> apply the policy check unconditionally. I would also suggest putting >> this entire block in a helper function. > will refer suggested API, and rework upon this. Thanks for the pointer -- I looked closely at cxl_region_decode_reset() and want to flag something before sending v3, since a literal port-walk doesn't fully replace the region lookup here. cxl_region_decode_reset() doesn't derive the decoder from the port walk alone: it's called with cxlr already known, and at each port level uses cxl_rr_load(iter, cxlr) -- keyed by the region -- to find the decoder assigned to that region at that port. The walk finds the *port*; cxlr still finds the *decoder*. The reason that matters for this check specifically: a single CXL root port can host multiple root decoders, one per CFMWS window, each with its own restrictions. A pure walk up to is_cxl_root(port) would tell us this decoder's SPA range originates somewhere under that root port, but not *which* of its root decoders' CFMWS restrictions apply -- only the region (or the port's region_ref tracking, which is also region-keyed) can disambiguate that. So v3 keeps the region-based lookup (cxld->region->dev.parent -> to_cxl_root_decoder()), but addresses what I take to be the actual concern -- silently skipping the policy check -- by making the check itself unconditional instead of gated: if (dev_WARN_ONCE(&cxld->dev, !cxld->region, "commit without region assignment\n")) return -ENXIO; A decoder reaching commit() without a region assigned is now treated as a bug (loud WARN + rejected commit) rather than something the check quietly steps around. By the time cxl_decoder_commit() runs, the region assignment has already happened during region assembly (cxl_rr_assign_decoder()), so this should not be reachable in practice. Also pulled the whole block into cxl_decoder_cfmws_check() as suggested. v3 to follow shortly with this and the F_DEVMEM/F_HOSTONLY rename per Davidlohr's BI series. Thanks, Mayank >> DJ >> >>> +        unsigned long required_flag = 0; >>> +        const char *type_name; >>> + >>> +        cxlrd = to_cxl_root_decoder(cxld->region->dev.parent); >>> +        if (cxld->target_type == CXL_DECODER_DEVMEM) { >>> +            required_flag = CXL_DECODER_F_TYPE2; >>> +            type_name = "HDM-DB"; >>> +        } else if (cxld->target_type == CXL_DECODER_HOSTONLYMEM) { >>> +            required_flag = CXL_DECODER_F_TYPE3; >>> +            type_name = "HDM-H"; >>> +        } >>> + >>> +        if (required_flag && !(cxlrd->cxlsd.cxld.flags & >>> required_flag)) { >>> +            dev_err(&port->dev, >>> +                "%s commit rejected on %s, CFMWS does not permit >>> this memory type\n", >>> +                type_name, dev_name(&cxld->dev)); >>> +            return -EOPNOTSUPP; >>> +        } >>> +    } >>> + >>>       scoped_guard(rwsem_read, &cxl_rwsem.dpa) >>>           setup_hw_decoder(cxld, hdm); >> > Regards, > Mayank >