acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
with the expectation that numa_cleanup_meminfo moves them to
numa_reserved_meminfo. There is no need for that indirection when it is
known in advance that these unpopulated ranges are meant for
numa_reserved_meminfo in support of future hotplug / CXL provisioning.

Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
ranges directly.

Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
---

Changes in v2 (Thanks to Dan & Alison):
- Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
- Add comments to describe the usage of numa_add_reserved_memblk()
- Updating the commit message to clarify the purpose of the patch

By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.

 drivers/acpi/numa/srat.c     |  2 +-
 include/linux/numa_memblks.h |  1 +
 mm/numa_memblks.c            | 22 ++++++++++++++++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 0a725e46d017..751774f0b4e5 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
 		return -EINVAL;
 	}
 
-	if (numa_add_memblk(node, start, end) < 0) {
+	if (numa_add_reserved_memblk(node, start, end) < 0) {
 		/* CXL driver must handle the NUMA_NO_NODE case */
 		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
 			node, start, end);
diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
index dd85613cdd86..991076cba7c5 100644
--- a/include/linux/numa_memblks.h
+++ b/include/linux/numa_memblks.h
@@ -22,6 +22,7 @@ struct numa_meminfo {
 };
 
 int __init numa_add_memblk(int nodeid, u64 start, u64 end);
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
 void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
 
 int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
index ff4054f4334d..541a99c4071a 100644
--- a/mm/numa_memblks.c
+++ b/mm/numa_memblks.c
@@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
 	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
 }
 
+/**
+ * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
+ * @nid: NUMA node ID of the new memblk
+ * @start: Start address of the new memblk
+ * @end: End address of the new memblk
+ *
+ * Add a new memblk to the numa_reserved_meminfo.
+ *
+ * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
+ * against memblock_type information and moves any that intersect reserved
+ * ranges to numa_reserved_meminfo. However, when that information is known
+ * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
+ * to numa_reserved_meminfo directly.
+ *
+ * RETURNS:
+ * 0 on success, -errno on failure.
+ */
+int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
+{
+	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
+}
+
 /**
  * numa_cleanup_meminfo - Cleanup a numa_meminfo
  * @mi: numa_meminfo to clean up
-- 
2.34.1

On Tue, 6 May 2025 14:22:45 +0800
Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:

> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
This is v2 take 2.  There were tags on the previous version (pre longarch
change).

Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

(Also Dan Williams).

Easiest option when this happens is spin a v3 with a change log to
say the loongarch issue is resolved and you picked up tags.


> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0a725e46d017..751774f0b4e5 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up

On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote:
> On Tue, 6 May 2025 14:22:45 +0800
> Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> 
> > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > with the expectation that numa_cleanup_meminfo moves them to
> > numa_reserved_meminfo. There is no need for that indirection when it is
> > known in advance that these unpopulated ranges are meant for
> > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > 
> > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > ranges directly.
> > 
> > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> This is v2 take 2.  There were tags on the previous version (pre longarch
> change).
> 
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> 
> (Also Dan Williams).
> 
> Easiest option when this happens is spin a v3 with a change log to
> say the loongarch issue is resolved and you picked up tags.
>
Hi Jonathan,

Thanks for your tips. Would this v2 version trigger the kernel test
robot? It seems like only a new version of patch would trigger that.
I would publish v3 of this patch as soon as possible. 

Yuquan
> 
> > ---
> > 
> > Changes in v2 (Thanks to Dan & Alison):
> > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > - Add comments to describe the usage of numa_add_reserved_memblk()
> > - Updating the commit message to clarify the purpose of the patch
> > 
> > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> > 
> >  drivers/acpi/numa/srat.c     |  2 +-
> >  include/linux/numa_memblks.h |  1 +
> >  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
> >  3 files changed, 24 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > index 0a725e46d017..751774f0b4e5 100644
> > --- a/drivers/acpi/numa/srat.c
> > +++ b/drivers/acpi/numa/srat.c
> > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> >  		return -EINVAL;
> >  	}
> >  
> > -	if (numa_add_memblk(node, start, end) < 0) {
> > +	if (numa_add_reserved_memblk(node, start, end) < 0) {
> >  		/* CXL driver must handle the NUMA_NO_NODE case */
> >  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> >  			node, start, end);
> > diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> > index dd85613cdd86..991076cba7c5 100644
> > --- a/include/linux/numa_memblks.h
> > +++ b/include/linux/numa_memblks.h
> > @@ -22,6 +22,7 @@ struct numa_meminfo {
> >  };
> >  
> >  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
> >  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
> >  
> >  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> > diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> > index ff4054f4334d..541a99c4071a 100644
> > --- a/mm/numa_memblks.c
> > +++ b/mm/numa_memblks.c
> > @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> >  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
> >  }
> >  
> > +/**
> > + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> > + * @nid: NUMA node ID of the new memblk
> > + * @start: Start address of the new memblk
> > + * @end: End address of the new memblk
> > + *
> > + * Add a new memblk to the numa_reserved_meminfo.
> > + *
> > + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> > + * against memblock_type information and moves any that intersect reserved
> > + * ranges to numa_reserved_meminfo. However, when that information is known
> > + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> > + * to numa_reserved_meminfo directly.
> > + *
> > + * RETURNS:
> > + * 0 on success, -errno on failure.
> > + */
> > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> > +{
> > +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> > +}
> > +
> >  /**
> >   * numa_cleanup_meminfo - Cleanup a numa_meminfo
> >   * @mi: numa_meminfo to clean up
>

On Thu, May 8, 2025 at 9:47 AM Yuquan Wang
<wangyuquan1236@phytium.com.cn> wrote:
>
> On Wed, May 07, 2025 at 05:24:36PM +0100, Jonathan Cameron wrote:
> > On Tue, 6 May 2025 14:22:45 +0800
> > Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> >
> > > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > > with the expectation that numa_cleanup_meminfo moves them to
> > > numa_reserved_meminfo. There is no need for that indirection when it is
> > > known in advance that these unpopulated ranges are meant for
> > > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > >
> > > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > > ranges directly.
> > >
> > > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> > This is v2 take 2.  There were tags on the previous version (pre longarch
> > change).
> >
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> >
> > (Also Dan Williams).
> >
> > Easiest option when this happens is spin a v3 with a change log to
> > say the loongarch issue is resolved and you picked up tags.
> >
> Hi Jonathan,
>
> Thanks for your tips. Would this v2 version trigger the kernel test
> robot? It seems like only a new version of patch would trigger that.
> I would publish v3 of this patch as soon as possible.

The kernel test robot operates on linux-next, so there's probably no errors now.

Huacai

>
> Yuquan
> >
> > > ---
> > >
> > > Changes in v2 (Thanks to Dan & Alison):
> > > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > > - Add comments to describe the usage of numa_add_reserved_memblk()
> > > - Updating the commit message to clarify the purpose of the patch
> > >
> > > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> > >
> > >  drivers/acpi/numa/srat.c     |  2 +-
> > >  include/linux/numa_memblks.h |  1 +
> > >  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
> > >  3 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> > > index 0a725e46d017..751774f0b4e5 100644
> > > --- a/drivers/acpi/numa/srat.c
> > > +++ b/drivers/acpi/numa/srat.c
> > > @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
> > >             return -EINVAL;
> > >     }
> > >
> > > -   if (numa_add_memblk(node, start, end) < 0) {
> > > +   if (numa_add_reserved_memblk(node, start, end) < 0) {
> > >             /* CXL driver must handle the NUMA_NO_NODE case */
> > >             pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
> > >                     node, start, end);
> > > diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> > > index dd85613cdd86..991076cba7c5 100644
> > > --- a/include/linux/numa_memblks.h
> > > +++ b/include/linux/numa_memblks.h
> > > @@ -22,6 +22,7 @@ struct numa_meminfo {
> > >  };
> > >
> > >  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
> > >  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
> > >
> > >  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> > > diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> > > index ff4054f4334d..541a99c4071a 100644
> > > --- a/mm/numa_memblks.c
> > > +++ b/mm/numa_memblks.c
> > > @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
> > >     return numa_add_memblk_to(nid, start, end, &numa_meminfo);
> > >  }
> > >
> > > +/**
> > > + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> > > + * @nid: NUMA node ID of the new memblk
> > > + * @start: Start address of the new memblk
> > > + * @end: End address of the new memblk
> > > + *
> > > + * Add a new memblk to the numa_reserved_meminfo.
> > > + *
> > > + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> > > + * against memblock_type information and moves any that intersect reserved
> > > + * ranges to numa_reserved_meminfo. However, when that information is known
> > > + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> > > + * to numa_reserved_meminfo directly.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, -errno on failure.
> > > + */
> > > +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> > > +{
> > > +   return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> > > +}
> > > +
> > >  /**
> > >   * numa_cleanup_meminfo - Cleanup a numa_meminfo
> > >   * @mi: numa_meminfo to clean up
> >
>

On Tue, May 06, 2025 at 02:22:45PM +0800, Yuquan Wang wrote:
> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
>  drivers/acpi/numa/srat.c     |  2 +-
>  include/linux/numa_memblks.h |  1 +
>  mm/numa_memblks.c            | 22 ++++++++++++++++++++++
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
> index 0a725e46d017..751774f0b4e5 100644
> --- a/drivers/acpi/numa/srat.c
> +++ b/drivers/acpi/numa/srat.c
> @@ -453,7 +453,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
>  		return -EINVAL;
>  	}
>  
> -	if (numa_add_memblk(node, start, end) < 0) {
> +	if (numa_add_reserved_memblk(node, start, end) < 0) {
>  		/* CXL driver must handle the NUMA_NO_NODE case */
>  		pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
>  			node, start, end);
> diff --git a/include/linux/numa_memblks.h b/include/linux/numa_memblks.h
> index dd85613cdd86..991076cba7c5 100644
> --- a/include/linux/numa_memblks.h
> +++ b/include/linux/numa_memblks.h
> @@ -22,6 +22,7 @@ struct numa_meminfo {
>  };
>  
>  int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end);
>  void __init numa_remove_memblk_from(int idx, struct numa_meminfo *mi);
>  
>  int __init numa_cleanup_meminfo(struct numa_meminfo *mi);
> diff --git a/mm/numa_memblks.c b/mm/numa_memblks.c
> index ff4054f4334d..541a99c4071a 100644
> --- a/mm/numa_memblks.c
> +++ b/mm/numa_memblks.c
> @@ -200,6 +200,28 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>  	return numa_add_memblk_to(nid, start, end, &numa_meminfo);
>  }
>  
> +/**
> + * numa_add_reserved_memblk - Add one numa_memblk to numa_reserved_meminfo
> + * @nid: NUMA node ID of the new memblk
> + * @start: Start address of the new memblk
> + * @end: End address of the new memblk
> + *
> + * Add a new memblk to the numa_reserved_meminfo.
> + *
> + * Usage Case: numa_cleanup_meminfo() reconciles all numa_memblk instances
> + * against memblock_type information and moves any that intersect reserved
> + * ranges to numa_reserved_meminfo. However, when that information is known
> + * ahead of time, we use numa_add_reserved_memblk() to add the numa_memblk
> + * to numa_reserved_meminfo directly.
> + *
> + * RETURNS:
> + * 0 on success, -errno on failure.
> + */
> +int __init numa_add_reserved_memblk(int nid, u64 start, u64 end)
> +{
> +	return numa_add_memblk_to(nid, start, end, &numa_reserved_meminfo);
> +}
> +
>  /**
>   * numa_cleanup_meminfo - Cleanup a numa_meminfo
>   * @mi: numa_meminfo to clean up
> -- 
> 2.34.1
> 

-- 
Sincerely yours,
Mike.

On Tue,  6 May 2025 14:22:45 +0800 Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:

> acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> with the expectation that numa_cleanup_meminfo moves them to
> numa_reserved_meminfo. There is no need for that indirection when it is
> known in advance that these unpopulated ranges are meant for
> numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> 
> Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> ranges directly.
> 
> Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> ---
> 
> Changes in v2 (Thanks to Dan & Alison):
> - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> - Add comments to describe the usage of numa_add_reserved_memblk()
> - Updating the commit message to clarify the purpose of the patch
> 
> By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.

So is this patch dependent upon "LoongArch: Introduce the numa_memblks
conversion"?

On Tue, May 06, 2025 at 06:55:44PM -0700, Andrew Morton wrote:
> On Tue,  6 May 2025 14:22:45 +0800 Yuquan Wang <wangyuquan1236@phytium.com.cn> wrote:
> 
> > acpi_parse_cfmws() currently adds empty CFMWS ranges to numa_meminfo
> > with the expectation that numa_cleanup_meminfo moves them to
> > numa_reserved_meminfo. There is no need for that indirection when it is
> > known in advance that these unpopulated ranges are meant for
> > numa_reserved_meminfo in support of future hotplug / CXL provisioning.
> > 
> > Introduce and use numa_add_reserved_memblk() to add the empty CFMWS
> > ranges directly.
> > 
> > Signed-off-by: Yuquan Wang <wangyuquan1236@phytium.com.cn>
> > ---
> > 
> > Changes in v2 (Thanks to Dan & Alison):
> > - Use numa_add_reserved_memblk() to replace numa_add_memblk() in acpi_parse_cfmws()
> > - Add comments to describe the usage of numa_add_reserved_memblk()
> > - Updating the commit message to clarify the purpose of the patch
> > 
> > By the way, "LoongArch: Introduce the numa_memblks conversion" is in linux-next.
> 
> So is this patch dependent upon "LoongArch: Introduce the numa_memblks
> conversion"?

Yes, the previous version of this patch failed to build on loongarch.

-- 
Sincerely yours,
Mike.