From: Andre Przywara <andre.przywara@arm.com>
To: Yin Li <yin.li@oss.qualcomm.com>,
James Morse <james.morse@arm.com>, Rob Herring <robh@kernel.org>,
Shanker Donthineni <sdonthineni@nvidia.com>,
Ben Horgan <ben.horgan@arm.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Reinette Chatre <reinette.chatre@intel.com>,
Fenghua Yu <fenghuay@nvidia.com>,
Jonathan Cameron <jic23@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Gavin Shan <gshan@redhat.com>
Cc: "Drew Fustini" <fustini@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Shaopeng Tan" <tan.shaopeng@jp.fujitsu.com>,
trilok.soni@oss.qualcomm.com, aiqun.yu@oss.qualcomm.com,
ganapatrao.kulkarni@oss.qualcomm.com,
"Srivathsa L Rao" <srivathsa.rao@oss.qualcomm.com>,
"Huang Yiwei" <huang.yiwei@oss.qualcomm.com>,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
driver-core@lists.linux.dev, devicetree@vger.kernel.org
Subject: Re: [PATCH RFC v2 04/10] cacheinfo: Expose the code to generate a cache-id from a device_node
Date: Mon, 14 Sep 2026 14:26:31 +0200 [thread overview]
Message-ID: <317682e8-63e7-4047-9106-deea7bf96388@arm.com> (raw)
In-Reply-To: <20260914-mpam-resctrl-dt-knp-support-v2-4-bf6645bb2f65@oss.qualcomm.com>
Hi,
On 9/14/26 11:37, Yin Li wrote:
> From: James Morse <james.morse@arm.com>
>
> The MPAM driver identifies caches by id for use with resctrl. It
> needs to know the cache-id when probe-ing, but the value isn't set
> in cacheinfo until device_initcall(). Even after device_initcall(),
> the cache-id is only available if at least one CPU associated with
> the cache is online.
>
> Instead of making the driver wait, expose the code that generates the
> cache-id. The parts of the MPAM driver that run early can use this to
> set up the resctrl structures before cacheinfo is ready in
> device_initcall().
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [ Yin Li: fix context conflicts in cacheinfo.c and cacheinfo.h; guard the
> cache_of_calculate_id() declaration with CONFIG_OF to prevent build
> errors when CONFIG_OF is not set ]
You can shorten that part in square brackets: doing adjustments due to
rebasing is surely implied, and you can shorten the rest, like:
[ Yin Li: guard cache_of_calculate_id() prototype ]
Speaking of which ...
> Signed-off-by: Yin Li <yin.li@oss.qualcomm.com>
> ---
> drivers/base/cacheinfo.c | 17 ++++++++++++-----
> include/linux/cacheinfo.h | 3 +++
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 9f9c72727a05..f75e7f64038b 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -226,8 +226,7 @@ static bool match_cache_node(struct device_node *cpu,
> #define arch_compact_of_hwid(_x) (_x)
> #endif
>
> -static void cache_of_set_id(struct cacheinfo *this_leaf,
> - struct device_node *cache_node)
> +u32 cache_of_calculate_id(struct device_node *cache_node)
> {
> struct device_node *cpu;
> u32 min_id = ~0;
> @@ -238,15 +237,23 @@ static void cache_of_set_id(struct cacheinfo *this_leaf,
> id = arch_compact_of_hwid(id);
> if (FIELD_GET(GENMASK_ULL(63, 32), id)) {
> of_node_put(cpu);
> - return;
> + return ~0;
> }
>
> if (match_cache_node(cpu, cache_node))
> min_id = min(min_id, id);
> }
>
> - if (min_id != ~0) {
> - this_leaf->id = min_id;
> + return min_id;
> +}
> +
> +static void cache_of_set_id(struct cacheinfo *this_leaf,
> + struct device_node *cache_node)
> +{
> + u32 id = cache_of_calculate_id(cache_node);
> +
> + if (id != ~0) {
> + this_leaf->id = id;
> this_leaf->attributes |= CACHE_ID;
> }
> }
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index fc879ac4cc4f..c33bb3c8bd63 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -113,6 +113,9 @@ int acpi_get_cache_info(unsigned int cpu,
> #endif
>
> const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
> +#ifdef CONFIG_OF
Why is that, exactly? First IIUC it's quite uncommon to use #ifdef
guards around prototypes (unless they are stubbed without the symbol
defined). Using types protected by those symbols if certainly another
reason, and it looks like this would be the case here, but I had no
trouble building the kernel for x86, where CONFIG_OF is not defined.
So can you share a .config example (or give a hint) as to where this
fails building?
And if it does, wouldn't it be better to always include <linux/of.h> in
that file instead? I think I see a similar pattern elsewhere
(rfkill-gpio.c, sound/ac97/bus.c).
Cheers,
Andre
> +u32 cache_of_calculate_id(struct device_node *np);
> +#endif
>
> /*
> * Get the cacheinfo structure for the cache associated with @cpu at
>
next prev parent reply other threads:[~2026-09-14 12:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 9:37 [PATCH RFC v2 00/10] arm-mpam: Add basic device tree support for resctrl Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 01/10] arm_mpam: Fix the RIS index range check in mpam_ris_create_locked Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 02/10] arm_mpam: Fix MSC MMIO window size off-by-one with resource_size() Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 03/10] dt-bindings: arm: Add MPAM MSC binding Yin Li
2026-09-14 14:41 ` Andre Przywara
2026-09-14 14:50 ` Andre Przywara
2026-09-15 2:49 ` Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 04/10] cacheinfo: Expose the code to generate a cache-id from a device_node Yin Li
2026-09-14 12:26 ` Andre Przywara [this message]
2026-09-15 6:49 ` Yin Li
2026-09-15 7:59 ` Andre Przywara
2026-09-16 2:29 ` Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 05/10] arm_mpam: Add device tree support for MSC probing Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 06/10] arm_mpam: Add support for memory controller MSC on DT platforms Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 07/10] arm_mpam: Fix mpam_dt_create_foundling_msc() to create MSC platform devices Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 08/10] dt-bindings: arm: Fix MPAM MSC binding schema and examples Yin Li
2026-09-14 9:37 ` [PATCH RFC v2 09/10] arm_mpam: Support MSC accessibility derivation from RIS nodes Yin Li
2026-09-14 9:37 ` [PATCH DNM RFC v2 10/10] arm64: dts: qcom: kaanapali: Add MPAM MSC nodes for the L2 caches Yin Li
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=317682e8-63e7-4047-9106-deea7bf96388@arm.com \
--to=andre.przywara@arm.com \
--cc=aiqun.yu@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=dakr@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=driver-core@lists.linux.dev \
--cc=fenghuay@nvidia.com \
--cc=fustini@kernel.org \
--cc=ganapatrao.kulkarni@oss.qualcomm.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshan@redhat.com \
--cc=huang.yiwei@oss.qualcomm.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jic23@kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=reinette.chatre@intel.com \
--cc=robh@kernel.org \
--cc=sdonthineni@nvidia.com \
--cc=srivathsa.rao@oss.qualcomm.com \
--cc=tan.shaopeng@jp.fujitsu.com \
--cc=trilok.soni@oss.qualcomm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®