mbox series

[v2,0/4] of: Common "memory-region" parsing

Message ID 20250423-dt-memory-region-v2-v2-0-2fbd6ebd3c88@kernel.org
Headers show
Series of: Common "memory-region" parsing | expand

Message

Rob Herring April 23, 2025, 7:42 p.m. UTC
While there's a common function to parse "memory-region" properties for
DMA pool regions, there's not anything for driver private regions. As a
result, drivers have resorted to parsing "memory-region" properties
themselves repeating the same pattern over and over. To fix this, this
series adds 2 functions to handle those cases:
of_reserved_mem_region_to_resource() and of_reserved_mem_region_count().

I've converted the whole tree, but just including remoteproc here as
it has the most cases. I intend to apply the first 3 patches for 6.16
so the driver conversions can be applied for 6.17.

A git tree with all the drivers converted is here[1].

v2:
- Fix of_dma_set_restricted_buffer() to maintain behavior on warning msg
- Export devm_ioremap_resource_wc()
- Rework handling of resource name to drop unit-address from name as it 
  was before.
- Link to v1: 
  https://lore.kernel.org/all/20250317232426.952188-1-robh@kernel.org

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/memory-region

Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Rob Herring (Arm) (4):
      of: reserved_mem: Add functions to parse "memory-region"
      of: Simplify of_dma_set_restricted_buffer() to use of_for_each_phandle()
      devres: Export devm_ioremap_resource_wc()
      remoteproc: Use of_reserved_mem_region_* functions for "memory-region"

 drivers/of/device.c                       | 31 +++++-------
 drivers/of/of_reserved_mem.c              | 80 +++++++++++++++++++++++++++++++
 drivers/remoteproc/imx_dsp_rproc.c        | 45 +++++++----------
 drivers/remoteproc/imx_rproc.c            | 68 +++++++++++---------------
 drivers/remoteproc/qcom_q6v5_adsp.c       | 24 ++++------
 drivers/remoteproc/qcom_q6v5_mss.c        | 60 ++++++++---------------
 drivers/remoteproc/qcom_q6v5_pas.c        | 69 ++++++++++----------------
 drivers/remoteproc/qcom_q6v5_wcss.c       | 25 ++++------
 drivers/remoteproc/qcom_wcnss.c           | 23 ++++-----
 drivers/remoteproc/rcar_rproc.c           | 36 ++++++--------
 drivers/remoteproc/st_remoteproc.c        | 41 ++++++++--------
 drivers/remoteproc/stm32_rproc.c          | 44 ++++++++---------
 drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +++++------
 drivers/remoteproc/ti_k3_m4_remoteproc.c  | 28 +++++------
 drivers/remoteproc/ti_k3_r5_remoteproc.c  | 28 +++++------
 drivers/remoteproc/xlnx_r5_remoteproc.c   | 51 ++++++++------------
 include/linux/of_reserved_mem.h           | 26 ++++++++++
 lib/devres.c                              |  1 +
 18 files changed, 339 insertions(+), 369 deletions(-)
---
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
change-id: 20250423-dt-memory-region-v2-a2b15caacc63

Best regards,

Comments

Arnaud POULIQUEN April 28, 2025, 8:07 a.m. UTC | #1
Hello Rob,

On 4/23/25 21:42, Rob Herring (Arm) wrote:
> Drivers with "memory-region" properties currently have to do their own
> parsing of "memory-region" properties. The result is all the drivers
> have similar patterns of a call to parse "memory-region" and then get
> the region's address and size. As this is a standard property, it should
> have common functions for drivers to use. Add new functions to count the
> number of regions and retrieve the region's address as a resource.
> 
> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> v2:
>  - Wrap function parameters
> ---
>  drivers/of/of_reserved_mem.c    | 80 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_reserved_mem.h | 26 ++++++++++++++
>  2 files changed, 106 insertions(+)
> 
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index ee2e31522d7e..f87915cce961 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -12,6 +12,7 @@
>  #define pr_fmt(fmt)	"OF: reserved mem: " fmt
>  
>  #include <linux/err.h>
> +#include <linux/ioport.h>
>  #include <linux/libfdt.h>
>  #include <linux/of.h>
>  #include <linux/of_fdt.h>
> @@ -740,3 +741,82 @@ struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
>  	return NULL;
>  }
>  EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
> +
> +/**
> + * of_reserved_mem_region_to_resource() - Get a reserved memory region as a resource
> + * @np:		node containing 'memory-region' property
> + * @idx:	index of 'memory-region' property to lookup
> + * @res:	Pointer to a struct resource to fill in with reserved region
> + *
> + * This function allows drivers to lookup a node's 'memory-region' property
> + * entries by index and return a struct resource for the entry.
> + *
> + * Returns 0 on success with @res filled in. Returns -ENODEV if 'memory-region'
> + * is missing or unavailable, -EINVAL for any other error.
> + */
> +int of_reserved_mem_region_to_resource(const struct device_node *np,
> +				       unsigned int idx, struct resource *res)
> +{
> +	struct reserved_mem *rmem;
> +
> +	if (!np)
> +		return -EINVAL;
> +
> +	struct device_node __free(device_node) *target = of_parse_phandle(np, "memory-region", idx);
> +	if (!target || !of_device_is_available(target))
> +		return -ENODEV;
> +
> +	rmem = of_reserved_mem_lookup(target);
> +	if (!rmem)
> +		return -EINVAL;
> +
> +	resource_set_range(res, rmem->base, rmem->size);
> +	res->name = rmem->name;
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_reserved_mem_region_to_resource);
> +
> +/**
> + * of_reserved_mem_region_to_resource_byname() - Get a reserved memory region as a resource
> + * @np:		node containing 'memory-region' property
> + * @name:	name of 'memory-region' property entry to lookup
> + * @res:	Pointer to a struct resource to fill in with reserved region
> + *
> + * This function allows drivers to lookup a node's 'memory-region' property
> + * entries by name and return a struct resource for the entry.
> + *
> + * Returns 0 on success with @res filled in. Returns -ENODEV if 'memory-region'
> + * is missing or unavailable, -EINVAL for any other error.

of_property_match_string() can return some other error values.

Thanks,
Arnaud

> + */
> +int of_reserved_mem_region_to_resource_byname(const struct device_node *np,
> +					      const char *name,
> +					      struct resource *res)
> +{
> +	int idx;
> +
> +	if (!name)
> +		return -EINVAL;
> +
> +	idx = of_property_match_string(np, "memory-region-names", name);
> +	if (idx < 0)
> +		return idx;
> +
> +	return of_reserved_mem_region_to_resource(np, idx, res);
> +}
> +EXPORT_SYMBOL_GPL(of_reserved_mem_region_to_resource_byname);
> +
> +/**
> + * of_reserved_mem_region_count() - Return the number of 'memory-region' entries
> + * @np:		node containing 'memory-region' property
> + *
> + * This function allows drivers to retrieve the number of entries for a node's
> + * 'memory-region' property.
> + *
> + * Returns the number of entries on success, or negative error code on a
> + * malformed property.
> + */
> +int of_reserved_mem_region_count(const struct device_node *np)
> +{
> +	return of_count_phandle_with_args(np, "memory-region", NULL);
> +}
> +EXPORT_SYMBOL_GPL(of_reserved_mem_region_count);
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> index e338282da652..f573423359f4 100644
> --- a/include/linux/of_reserved_mem.h
> +++ b/include/linux/of_reserved_mem.h
> @@ -7,6 +7,7 @@
>  
>  struct of_phandle_args;
>  struct reserved_mem_ops;
> +struct resource;
>  
>  struct reserved_mem {
>  	const char			*name;
> @@ -39,6 +40,12 @@ int of_reserved_mem_device_init_by_name(struct device *dev,
>  void of_reserved_mem_device_release(struct device *dev);
>  
>  struct reserved_mem *of_reserved_mem_lookup(struct device_node *np);
> +int of_reserved_mem_region_to_resource(const struct device_node *np,
> +				       unsigned int idx, struct resource *res);
> +int of_reserved_mem_region_to_resource_byname(const struct device_node *np,
> +					      const char *name, struct resource *res);
> +int of_reserved_mem_region_count(const struct device_node *np);
> +
>  #else
>  
>  #define RESERVEDMEM_OF_DECLARE(name, compat, init)			\
> @@ -63,6 +70,25 @@ static inline struct reserved_mem *of_reserved_mem_lookup(struct device_node *np
>  {
>  	return NULL;
>  }
> +
> +static inline int of_reserved_mem_region_to_resource(const struct device_node *np,
> +						     unsigned int idx,
> +						     struct resource *res)
> +{
> +	return -ENOSYS;
> +}
> +
> +static inline int of_reserved_mem_region_to_resource_byname(const struct device_node *np,
> +							    const char *name,
> +							    struct resource *res)
> +{
> +	return -ENOSYS;
> +}
> +
> +static inline int of_reserved_mem_region_count(const struct device_node *np)
> +{
> +	return 0;
> +}
>  #endif
>  
>  /**
>
Arnaud POULIQUEN April 28, 2025, 8:16 a.m. UTC | #2
On 4/23/25 21:42, Rob Herring (Arm) wrote:
> While there's a common function to parse "memory-region" properties for
> DMA pool regions, there's not anything for driver private regions. As a
> result, drivers have resorted to parsing "memory-region" properties
> themselves repeating the same pattern over and over. To fix this, this
> series adds 2 functions to handle those cases:
> of_reserved_mem_region_to_resource() and of_reserved_mem_region_count().
> 
> I've converted the whole tree, but just including remoteproc here as
> it has the most cases. I intend to apply the first 3 patches for 6.16
> so the driver conversions can be applied for 6.17.
> 
> A git tree with all the drivers converted is here[1].
> 
> v2:
> - Fix of_dma_set_restricted_buffer() to maintain behavior on warning msg
> - Export devm_ioremap_resource_wc()
> - Rework handling of resource name to drop unit-address from name as it 
>   was before.
> - Link to v1: 
>   https://lore.kernel.org/all/20250317232426.952188-1-robh@kernel.org
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/memory-region
> 
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Rob Herring (Arm) (4):
>       of: reserved_mem: Add functions to parse "memory-region"
>       of: Simplify of_dma_set_restricted_buffer() to use of_for_each_phandle()
>       devres: Export devm_ioremap_resource_wc()
>       remoteproc: Use of_reserved_mem_region_* functions for "memory-region"
> 
>  drivers/of/device.c                       | 31 +++++-------
>  drivers/of/of_reserved_mem.c              | 80 +++++++++++++++++++++++++++++++
>  drivers/remoteproc/imx_dsp_rproc.c        | 45 +++++++----------
>  drivers/remoteproc/imx_rproc.c            | 68 +++++++++++---------------
>  drivers/remoteproc/qcom_q6v5_adsp.c       | 24 ++++------
>  drivers/remoteproc/qcom_q6v5_mss.c        | 60 ++++++++---------------
>  drivers/remoteproc/qcom_q6v5_pas.c        | 69 ++++++++++----------------
>  drivers/remoteproc/qcom_q6v5_wcss.c       | 25 ++++------
>  drivers/remoteproc/qcom_wcnss.c           | 23 ++++-----
>  drivers/remoteproc/rcar_rproc.c           | 36 ++++++--------
>  drivers/remoteproc/st_remoteproc.c        | 41 ++++++++--------
>  drivers/remoteproc/stm32_rproc.c          | 44 ++++++++---------
>  drivers/remoteproc/ti_k3_dsp_remoteproc.c | 28 +++++------
>  drivers/remoteproc/ti_k3_m4_remoteproc.c  | 28 +++++------
>  drivers/remoteproc/ti_k3_r5_remoteproc.c  | 28 +++++------
>  drivers/remoteproc/xlnx_r5_remoteproc.c   | 51 ++++++++------------
>  include/linux/of_reserved_mem.h           | 26 ++++++++++
>  lib/devres.c                              |  1 +
>  18 files changed, 339 insertions(+), 369 deletions(-)
> ---
> base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
> change-id: 20250423-dt-memory-region-v2-a2b15caacc63
> 

Testing of the series on the STM32MP15 platform has passed.

just one minor comment in patch 1/4.

Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>

Thanks,
Arnaud




> Best regards,
Rob Herring April 28, 2025, 12:23 p.m. UTC | #3
On Fri, Apr 25, 2025 at 6:34 PM Iuliana Prodan <iuliana.prodan@nxp.com> wrote:
>
> Hello Mathieu, Rob,
>
> I've tested imx_dsp_rproc and it fails with:
>
> [   39.743770] Unable to handle kernel paging request at virtual address
> ffffffffffffffea
> ...
> [   39.805078] Hardware name: NXP i.MX8MPlus EVK board (DT)
> [   39.810390] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [   39.817353] pc : __pi_memset_generic+0x50/0x188
> [   39.821892] lr : imx_dsp_rproc_prepare+0x3a4/0xea4 [imx_dsp_rproc]
> [   39.828079] sp : ffff8000853dbb10
> [   39.831396] x29: ffff8000853dbb90 x28: 0000000092400000 x27:
> ffff80007a36d3d8
> [   39.838540] x26: ffff0000d0a5e410 x25: ffff80007a36d3f0 x24:
> 0000000000000004
> [   39.845685] x23: ffff0000d5414880 x22: ffff0000d5e1dce8 x21:
> 0000000000000000
> [   39.852827] x20: ffff0000d5e1db98 x19: ffff0000d5414b80 x18:
> 00000000ffffffff
> [   39.859970] x17: 202c656c69687720 x16: 3e2074756f657672 x15:
> ffff800081f8d050
> [   39.867114] x14: ffff0000db584680 x13: 0000000000000003 x12:
> 00007fffa3330000
> [   39.874257] x11: 0000000000000004 x10: 0000000000000ab0 x9 :
> 0000000000000000
> [   39.881400] x8 : ffffffffffffffea x7 : 0000000000000000 x6 :
> 000000000000003f
> [   39.888546] x5 : 0000000000000040 x4 : 0000000000000006 x3 :
> 0000000000000004
> [   39.895689] x2 : 0000000000008000 x1 : 0000000000000000 x0 :
> ffffffffffffffea
> [   39.902837] Call trace:
> [   39.905284]  __pi_memset_generic+0x50/0x188 (P)
> [   39.909821]  rproc_boot+0x2c0/0x524
> [   39.913317]  state_store+0x40/0x100
> [   39.916812]  dev_attr_store+0x18/0x2c
> [   39.920478]  sysfs_kf_write+0x7c/0x94
> [   39.924146]  kernfs_fop_write_iter+0x120/0x1e8
> [   39.928598]  vfs_write+0x244/0x37c
> [   39.932008]  ksys_write+0x70/0x110
> [   39.935413]  __arm64_sys_write+0x1c/0x28
> [   39.939342]  invoke_syscall+0x48/0x104
> [   39.943094]  el0_svc_common.constprop.0+0xc0/0xe0
> [   39.947805]  do_el0_svc+0x1c/0x28
> [   39.951123]  el0_svc+0x30/0xcc
> [   39.954188]  el0t_64_sync_handler+0x10c/0x138
> [   39.958549]  el0t_64_sync+0x198/0x19c
> [   39.962222] Code: d65f03c0 cb0803e4 f2400c84 54000080 (a9001d07)
> [   39.968317] ---[ end trace 0000000000000000 ]---
>
> The problem seems to be when computing `cpu_addr =
> devm_ioremap_resource_wc(dev, &res);`, in patch 4.
> In `__devm_ioremap_resource` (see [1]), it's expecting the resource type
> to be `IORESOURCE_MEM`, which is not the case here (at least the flags
> are nowhere set for this).

Thanks for testing and diagnosing. IORESOURCE_MEM needs to be set. Can
you test with this change:

index f87915cce961..00c93585758f 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -771,6 +771,7 @@ int of_reserved_mem_region_to_resource(const
struct device_node *np,
                return -EINVAL;

        resource_set_range(res, rmem->base, rmem->size);
+       res->flags = IORESOURCE_MEM;
        res->name = rmem->name;
        return 0;
 }
Iuliana Prodan April 28, 2025, 9:40 p.m. UTC | #4
On 4/28/2025 3:23 PM, Rob Herring wrote:
> On Fri, Apr 25, 2025 at 6:34 PM Iuliana Prodan <iuliana.prodan@nxp.com> wrote:
>> Hello Mathieu, Rob,
>>
>> I've tested imx_dsp_rproc and it fails with:
>>
>> [   39.743770] Unable to handle kernel paging request at virtual address
>> ffffffffffffffea
>> ...
>> [   39.805078] Hardware name: NXP i.MX8MPlus EVK board (DT)
>> [   39.810390] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS
>> BTYPE=--)
>> [   39.817353] pc : __pi_memset_generic+0x50/0x188
>> [   39.821892] lr : imx_dsp_rproc_prepare+0x3a4/0xea4 [imx_dsp_rproc]
>> [   39.828079] sp : ffff8000853dbb10
>> [   39.831396] x29: ffff8000853dbb90 x28: 0000000092400000 x27:
>> ffff80007a36d3d8
>> [   39.838540] x26: ffff0000d0a5e410 x25: ffff80007a36d3f0 x24:
>> 0000000000000004
>> [   39.845685] x23: ffff0000d5414880 x22: ffff0000d5e1dce8 x21:
>> 0000000000000000
>> [   39.852827] x20: ffff0000d5e1db98 x19: ffff0000d5414b80 x18:
>> 00000000ffffffff
>> [   39.859970] x17: 202c656c69687720 x16: 3e2074756f657672 x15:
>> ffff800081f8d050
>> [   39.867114] x14: ffff0000db584680 x13: 0000000000000003 x12:
>> 00007fffa3330000
>> [   39.874257] x11: 0000000000000004 x10: 0000000000000ab0 x9 :
>> 0000000000000000
>> [   39.881400] x8 : ffffffffffffffea x7 : 0000000000000000 x6 :
>> 000000000000003f
>> [   39.888546] x5 : 0000000000000040 x4 : 0000000000000006 x3 :
>> 0000000000000004
>> [   39.895689] x2 : 0000000000008000 x1 : 0000000000000000 x0 :
>> ffffffffffffffea
>> [   39.902837] Call trace:
>> [   39.905284]  __pi_memset_generic+0x50/0x188 (P)
>> [   39.909821]  rproc_boot+0x2c0/0x524
>> [   39.913317]  state_store+0x40/0x100
>> [   39.916812]  dev_attr_store+0x18/0x2c
>> [   39.920478]  sysfs_kf_write+0x7c/0x94
>> [   39.924146]  kernfs_fop_write_iter+0x120/0x1e8
>> [   39.928598]  vfs_write+0x244/0x37c
>> [   39.932008]  ksys_write+0x70/0x110
>> [   39.935413]  __arm64_sys_write+0x1c/0x28
>> [   39.939342]  invoke_syscall+0x48/0x104
>> [   39.943094]  el0_svc_common.constprop.0+0xc0/0xe0
>> [   39.947805]  do_el0_svc+0x1c/0x28
>> [   39.951123]  el0_svc+0x30/0xcc
>> [   39.954188]  el0t_64_sync_handler+0x10c/0x138
>> [   39.958549]  el0t_64_sync+0x198/0x19c
>> [   39.962222] Code: d65f03c0 cb0803e4 f2400c84 54000080 (a9001d07)
>> [   39.968317] ---[ end trace 0000000000000000 ]---
>>
>> The problem seems to be when computing `cpu_addr =
>> devm_ioremap_resource_wc(dev, &res);`, in patch 4.
>> In `__devm_ioremap_resource` (see [1]), it's expecting the resource type
>> to be `IORESOURCE_MEM`, which is not the case here (at least the flags
>> are nowhere set for this).
> Thanks for testing and diagnosing. IORESOURCE_MEM needs to be set. Can
> you test with this change:
>
> index f87915cce961..00c93585758f 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -771,6 +771,7 @@ int of_reserved_mem_region_to_resource(const
> struct device_node *np,
>                  return -EINVAL;
>
>          resource_set_range(res, rmem->base, rmem->size);
> +       res->flags = IORESOURCE_MEM;
>          res->name = rmem->name;
>          return 0;
>   }

I've tested with this change, and is all good now. Iulia