From: sashiko-bot@kernel.org
To: "Yin Li" <yin.li@oss.qualcomm.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v3 6/8] arm_mpam: Add support for memory controller MSC on DT platforms
Date: Thu, 08 Oct 2026 07:00:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-163726@kernel.org> (raw)
In-Reply-To: <20261008-mpam-resctrl-dt-knp-support-v3-6-35196c2b43bf@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] of: memory controller MSC probe failure due to incorrect DT compatible match
- [High] arm_mpam: memory controller MSC accessibility mask left empty due to invalid 'memory' compatible check
--
commit b661da0a277e50a0881896ca5067c92dd25c983b
Author: Shanker Donthineni <sdonthineni@nvidia.com>
arm_mpam: Add support for memory controller MSC on DT platforms
This commit adds support to discover memory-controller MSCs from the device
tree. It derives the component id from the NUMA node, creates a memory class
RIS, and treats a memory parent as accessible from all CPUs.
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
[ ... ]
> @@ -2169,6 +2192,8 @@ static void update_msc_accessibility(struct mpam_msc *msc)
> } else {
> if (of_device_is_compatible(parent, "cache"))
> get_cpumask_from_cache(parent, &msc->accessibility);
> + else if (of_device_is_compatible(parent, "memory"))
[Severity: High]
Does this compatible check actually work for memory nodes?
The of_device_is_compatible() API strictly matches the provided string against
the compatible property array of the device tree node. However, standard
Device Tree memory nodes are identified by device_type = "memory" and do not
have a compatible = "memory" property. Additionally, vendor-specific memory
controllers do not include the generic string "memory" in their compatible
lists.
Since there is no valid node in the kernel with compatible = "memory", will
this check unconditionally fail?
If so, it appears the driver will fall through to the else branch, leave
msc->accessibility uninitialized (empty), and cause the probe to return
-EINVAL, permanently failing the initialization of all memory-class MSCs.
> + cpumask_copy(&msc->accessibility, cpu_possible_mask);
> else
> dev_err_once(dev, "Cannot determine accessibility of MSC.\n");
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008-mpam-resctrl-dt-knp-support-v3-0-35196c2b43bf@oss.qualcomm.com?part=6
next prev parent reply other threads:[~2026-10-08 7:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 6:41 [PATCH v3 0/8] arm-mpam: Add basic device tree support for resctrl Yin Li
2026-10-08 6:41 ` [PATCH v3 1/8] arm_mpam: Fix the RIS index range check in mpam_ris_create_locked Yin Li
2026-10-08 6:41 ` [PATCH v3 2/8] arm_mpam: Fix MSC MMIO window size off-by-one with resource_size() Yin Li
2026-10-08 6:41 ` [PATCH v3 3/8] dt-bindings: arm: Add MPAM MSC binding Yin Li
2026-10-08 21:27 ` Rob Herring
2026-10-12 7:05 ` Yin Li
2026-10-12 10:24 ` Yin Li
2026-10-08 6:41 ` [PATCH v3 4/8] cacheinfo: Expose the code to generate a cache-id from a device_node Yin Li
2026-10-08 6:55 ` sashiko-bot
2026-10-08 6:41 ` [PATCH v3 5/8] arm_mpam: Add device tree support for MSC probing Yin Li
2026-10-08 6:57 ` sashiko-bot
2026-10-08 6:41 ` [PATCH v3 6/8] arm_mpam: Add support for memory controller MSC on DT platforms Yin Li
2026-10-08 7:00 ` sashiko-bot [this message]
2026-10-08 21:29 ` Rob Herring
2026-10-12 10:11 ` Yin Li
2026-10-08 6:41 ` [PATCH v3 7/8] arm_mpam: Support MSC accessibility derivation from RIS nodes Yin Li
2026-10-08 6:59 ` sashiko-bot
2026-10-08 6:41 ` [PATCH DNM v3 8/8] arm64: dts: qcom: kaanapali: Add MPAM MSC nodes for the L2 caches Yin Li
2026-10-08 6:55 ` sashiko-bot
2026-10-08 21:00 ` Rob Herring
2026-10-12 10:48 ` Yin Li
2026-10-12 11:27 ` Ben Horgan
2026-10-13 10:13 ` Yin Li
2026-10-13 10:37 ` Ben Horgan
2026-10-13 10:54 ` Konrad Dybcio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-163726@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yin.li@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.