Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-02-28 Thread MD Danish Anwar 



On 28/02/24 4:12 pm, Roger Quadros wrote:
> 
> 
> On 28/02/2024 12:35, MD Danish Anwar wrote:
>>
>>
>> On 28/02/24 3:30 pm, Roger Quadros wrote:
>>>
>>>
>>> On 17/02/2024 14:26, MD Danish Anwar wrote:
 Add APIs to set a firmware_name to a rproc and boot the rproc with the
 same firmware.

 Clients can call rproc_set_firmware() API to set firmware_name for a rproc
 whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
 a buffer by calling request_firmware_into_buf(). rproc_boot() will then
 load the firmware file to the remote processor and start the remote
 processor.

 Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
 Kconfig so that we can call request_firmware_into_buf() from remoteproc
 driver.

 Signed-off-by: MD Danish Anwar 
 ---
 Changes from v4 to v5:
 *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
that can be loaded to a rproc.
 *) Added freeing of address in rproc_boot() as pointed out by Ravi.
 *) Allocating the address at a later point in rproc_boot()
 *) Rebased on latest u-boot/master [commit 
9e00b6993f724da9699ef12573307afea8c19284]

 Changes from v3 to v4:
 *) No functional change. Splitted the patch out of the series as suggested
by Nishant.
 *) Droppped the RFC tag.

 v4: 
 https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
 v3: 
 https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/

  drivers/remoteproc/Kconfig|   8 +++
  drivers/remoteproc/rproc-uclass.c | 100 ++
  include/remoteproc.h  |  34 ++
  3 files changed, 142 insertions(+)

 diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
 index 781de530af..759d21437a 100644
 --- a/drivers/remoteproc/Kconfig
 +++ b/drivers/remoteproc/Kconfig
 @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
  # All users should depend on DM
  config REMOTEPROC
bool
 +  select FS_LOADER
depends on DM
  
  # Please keep the configuration alphabetically sorted.
 @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
help
  Say 'y' here to add support for TI' K3 remoteproc driver.
  
 +config REMOTEPROC_MAX_FW_SIZE
 +  hex "Maximum size of firmware that needs to be loaded to rproc"
>>>
>>> firmware file?
>>>
>>> /rproc/the remote processor
>>>
 +  default 0x1
 +  help
 +Maximum size of the firmware file (elf, binary) that needs to be
 +loaded to th rproc core.
>>>
>>> s/th/the
>>> s/rproc/remote processor
>>>
>>
>> Will fix these typos.
>>
 +
  endmenu
 diff --git a/drivers/remoteproc/rproc-uclass.c 
 b/drivers/remoteproc/rproc-uclass.c
 index 28b362c887..784361cef9 100644
 --- a/drivers/remoteproc/rproc-uclass.c
 +++ b/drivers/remoteproc/rproc-uclass.c
 @@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
 udevice *dev, struct rproc *cfg)
  
return 1;
  }
 +
 +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
 +{
 +  struct dm_rproc_uclass_pdata *uc_pdata;
 +  int len;
 +  char *p;
 +
 +  if (!rproc_dev || !fw_name)
 +  return -EINVAL;
 +
 +  uc_pdata = dev_get_uclass_plat(rproc_dev);
 +  if (!uc_pdata)
 +  return -EINVAL;
 +
 +  len = strcspn(fw_name, "\n");
 +  if (!len) {
 +  debug("invalid firmware name\n");
 +  return -EINVAL;
 +  }
 +
 +  p = strndup(fw_name, len);
 +  if (!p)
 +  return -ENOMEM;
>>>
>>> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
>>> Can we check if uc_pdata->fw_name exists and free it before the strndup?
>>>
>>
>> Sure, How does the below diff looks to you?
>>
>> diff --git a/drivers/remoteproc/rproc-uclass.c
>> b/drivers/remoteproc/rproc-uclass.c
>> index 784361cef9..f373b64da4 100644
>> --- a/drivers/remoteproc/rproc-uclass.c
>> +++ b/drivers/remoteproc/rproc-uclass.c
>> @@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
>> const char *fw_name)
>> return -EINVAL;
>> }
>>
>> +   if (uc_pdata->fw_name)
>> +   free(uc_pdata->fw_name);
>> +
>> p = strndup(fw_name, len);
>> if (!p)
>> return -ENOMEM;
> 
> This is OK. Please see below.
> 
>>
>>
 +
 +  uc_pdata->fw_name = p;
 +
 +  return 0;
 +}
 +
 +int rproc_boot(struct udevice *rproc_dev)
 +{
 +  struct dm_rproc_uclass_pdata *uc_pdata;
 +  struct udevice *fs_loader;
 +  int core_id, ret = 0;
 +  char *firmware;

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-02-28 Thread Roger Quadros 



On 28/02/2024 12:35, MD Danish Anwar wrote:
> 
> 
> On 28/02/24 3:30 pm, Roger Quadros wrote:
>>
>>
>> On 17/02/2024 14:26, MD Danish Anwar wrote:
>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>> same firmware.
>>>
>>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>>> load the firmware file to the remote processor and start the remote
>>> processor.
>>>
>>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>>> driver.
>>>
>>> Signed-off-by: MD Danish Anwar 
>>> ---
>>> Changes from v4 to v5:
>>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>>that can be loaded to a rproc.
>>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>>> *) Allocating the address at a later point in rproc_boot()
>>> *) Rebased on latest u-boot/master [commit 
>>>9e00b6993f724da9699ef12573307afea8c19284]
>>>
>>> Changes from v3 to v4:
>>> *) No functional change. Splitted the patch out of the series as suggested
>>>by Nishant.
>>> *) Droppped the RFC tag.
>>>
>>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>>
>>>  drivers/remoteproc/Kconfig|   8 +++
>>>  drivers/remoteproc/rproc-uclass.c | 100 ++
>>>  include/remoteproc.h  |  34 ++
>>>  3 files changed, 142 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>> index 781de530af..759d21437a 100644
>>> --- a/drivers/remoteproc/Kconfig
>>> +++ b/drivers/remoteproc/Kconfig
>>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>>  # All users should depend on DM
>>>  config REMOTEPROC
>>> bool
>>> +   select FS_LOADER
>>> depends on DM
>>>  
>>>  # Please keep the configuration alphabetically sorted.
>>> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>>> help
>>>   Say 'y' here to add support for TI' K3 remoteproc driver.
>>>  
>>> +config REMOTEPROC_MAX_FW_SIZE
>>> +   hex "Maximum size of firmware that needs to be loaded to rproc"
>>
>> firmware file?
>>
>> /rproc/the remote processor
>>
>>> +   default 0x1
>>> +   help
>>> + Maximum size of the firmware file (elf, binary) that needs to be
>>> + loaded to th rproc core.
>>
>> s/th/the
>> s/rproc/remote processor
>>
> 
> Will fix these typos.
> 
>>> +
>>>  endmenu
>>> diff --git a/drivers/remoteproc/rproc-uclass.c 
>>> b/drivers/remoteproc/rproc-uclass.c
>>> index 28b362c887..784361cef9 100644
>>> --- a/drivers/remoteproc/rproc-uclass.c
>>> +++ b/drivers/remoteproc/rproc-uclass.c
>>> @@ -13,6 +13,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
>>> udevice *dev, struct rproc *cfg)
>>>  
>>> return 1;
>>>  }
>>> +
>>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>>> +{
>>> +   struct dm_rproc_uclass_pdata *uc_pdata;
>>> +   int len;
>>> +   char *p;
>>> +
>>> +   if (!rproc_dev || !fw_name)
>>> +   return -EINVAL;
>>> +
>>> +   uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> +   if (!uc_pdata)
>>> +   return -EINVAL;
>>> +
>>> +   len = strcspn(fw_name, "\n");
>>> +   if (!len) {
>>> +   debug("invalid firmware name\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   p = strndup(fw_name, len);
>>> +   if (!p)
>>> +   return -ENOMEM;
>>
>> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
>> Can we check if uc_pdata->fw_name exists and free it before the strndup?
>>
> 
> Sure, How does the below diff looks to you?
> 
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 784361cef9..f373b64da4 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
> const char *fw_name)
> return -EINVAL;
> }
> 
> +   if (uc_pdata->fw_name)
> +   free(uc_pdata->fw_name);
> +
> p = strndup(fw_name, len);
> if (!p)
> return -ENOMEM;

This is OK. Please see below.

> 
> 
>>> +
>>> +   uc_pdata->fw_name = p;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int rproc_boot(struct udevice *rproc_dev)
>>> +{
>>> +   struct dm_rproc_uclass_pdata *uc_pdata;
>>> +   struct udevice *fs_loader;
>>> +   int core_id, ret = 0;
>>> +   char *firmware;
>>> +   void *addr;
>>> +
>>> +   if (!rproc_dev)
>>> +   return -EINVAL;
>>> +
>>> +   uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> +   if (!uc_pdata)
>>> +   return

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-02-28 Thread MD Danish Anwar 



On 28/02/24 3:30 pm, Roger Quadros wrote:
> 
> 
> On 17/02/2024 14:26, MD Danish Anwar wrote:
>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>> same firmware.
>>
>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>> load the firmware file to the remote processor and start the remote
>> processor.
>>
>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>> driver.
>>
>> Signed-off-by: MD Danish Anwar 
>> ---
>> Changes from v4 to v5:
>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>that can be loaded to a rproc.
>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>> *) Allocating the address at a later point in rproc_boot()
>> *) Rebased on latest u-boot/master [commit 
>>9e00b6993f724da9699ef12573307afea8c19284]
>>
>> Changes from v3 to v4:
>> *) No functional change. Splitted the patch out of the series as suggested
>>by Nishant.
>> *) Droppped the RFC tag.
>>
>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>
>>  drivers/remoteproc/Kconfig|   8 +++
>>  drivers/remoteproc/rproc-uclass.c | 100 ++
>>  include/remoteproc.h  |  34 ++
>>  3 files changed, 142 insertions(+)
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 781de530af..759d21437a 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>  # All users should depend on DM
>>  config REMOTEPROC
>>  bool
>> +select FS_LOADER
>>  depends on DM
>>  
>>  # Please keep the configuration alphabetically sorted.
>> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>>  help
>>Say 'y' here to add support for TI' K3 remoteproc driver.
>>  
>> +config REMOTEPROC_MAX_FW_SIZE
>> +hex "Maximum size of firmware that needs to be loaded to rproc"
> 
> firmware file?
> 
> /rproc/the remote processor
> 
>> +default 0x1
>> +help
>> +  Maximum size of the firmware file (elf, binary) that needs to be
>> +  loaded to th rproc core.
> 
> s/th/the
> s/rproc/remote processor
> 

Will fix these typos.

>> +
>>  endmenu
>> diff --git a/drivers/remoteproc/rproc-uclass.c 
>> b/drivers/remoteproc/rproc-uclass.c
>> index 28b362c887..784361cef9 100644
>> --- a/drivers/remoteproc/rproc-uclass.c
>> +++ b/drivers/remoteproc/rproc-uclass.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
>> udevice *dev, struct rproc *cfg)
>>  
>>  return 1;
>>  }
>> +
>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>> +{
>> +struct dm_rproc_uclass_pdata *uc_pdata;
>> +int len;
>> +char *p;
>> +
>> +if (!rproc_dev || !fw_name)
>> +return -EINVAL;
>> +
>> +uc_pdata = dev_get_uclass_plat(rproc_dev);
>> +if (!uc_pdata)
>> +return -EINVAL;
>> +
>> +len = strcspn(fw_name, "\n");
>> +if (!len) {
>> +debug("invalid firmware name\n");
>> +return -EINVAL;
>> +}
>> +
>> +p = strndup(fw_name, len);
>> +if (!p)
>> +return -ENOMEM;
> 
> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
> Can we check if uc_pdata->fw_name exists and free it before the strndup?
> 

Sure, How does the below diff looks to you?

diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index 784361cef9..f373b64da4 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
const char *fw_name)
return -EINVAL;
}

+   if (uc_pdata->fw_name)
+   free(uc_pdata->fw_name);
+
p = strndup(fw_name, len);
if (!p)
return -ENOMEM;


>> +
>> +uc_pdata->fw_name = p;
>> +
>> +return 0;
>> +}
>> +
>> +int rproc_boot(struct udevice *rproc_dev)
>> +{
>> +struct dm_rproc_uclass_pdata *uc_pdata;
>> +struct udevice *fs_loader;
>> +int core_id, ret = 0;
>> +char *firmware;
>> +void *addr;
>> +
>> +if (!rproc_dev)
>> +return -EINVAL;
>> +
>> +uc_pdata = dev_get_uclass_plat(rproc_dev);
>> +if (!uc_pdata)
>> +return -EINVAL;
>> +
>> +core_id = dev_seq(rproc_dev);
>> +firmware = uc_pdata->fw_name;
>> +
> unnecessary blank line.
> 
>> +if (!firmware) {
>> +debug("No firmware set for rproc core %d\n", core_id);
>

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-02-28 Thread Roger Quadros 



On 17/02/2024 14:26, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
> 
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
> 
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
> 
> Signed-off-by: MD Danish Anwar 
> ---
> Changes from v4 to v5:
> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>that can be loaded to a rproc.
> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
> *) Allocating the address at a later point in rproc_boot()
> *) Rebased on latest u-boot/master [commit 
>9e00b6993f724da9699ef12573307afea8c19284]
> 
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
> 
> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
> 
>  drivers/remoteproc/Kconfig|   8 +++
>  drivers/remoteproc/rproc-uclass.c | 100 ++
>  include/remoteproc.h  |  34 ++
>  3 files changed, 142 insertions(+)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..759d21437a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>  # All users should depend on DM
>  config REMOTEPROC
>   bool
> + select FS_LOADER
>   depends on DM
>  
>  # Please keep the configuration alphabetically sorted.
> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>   help
> Say 'y' here to add support for TI' K3 remoteproc driver.
>  
> +config REMOTEPROC_MAX_FW_SIZE
> + hex "Maximum size of firmware that needs to be loaded to rproc"

firmware file?

/rproc/the remote processor

> + default 0x1
> + help
> +   Maximum size of the firmware file (elf, binary) that needs to be
> +   loaded to th rproc core.

s/th/the
s/rproc/remote processor

> +
>  endmenu
> diff --git a/drivers/remoteproc/rproc-uclass.c 
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..784361cef9 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct udevice 
> *dev, struct rproc *cfg)
>  
>   return 1;
>  }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("invalid firmware name\n");
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;

Aren't we leaking memory if rproc_set_firmware() is called multiple times?
Can we check if uc_pdata->fw_name exists and free it before the strndup?

> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + int core_id, ret = 0;
> + char *firmware;
> + void *addr;
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
unnecessary blank line.

> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);

No firmware name...

> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + if (!rproc_is_initialized()) {
> + ret = rproc_init();
> + if (ret) {
> + debug("rproc_init() failed: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + if (CONFIG_REMOTEPROC_MAX_FW_SIZE) {

if (defined(CONFIG_REMOTEPROC_MAX_FW_SIZE)) {

> + addr = malloc(CONFIG_REMOTEPROC_MAX_FW_SIZE);
> +

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

2024-02-27 Thread Ravi Gunasekaran 



On 2/17/24 5:56 PM, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
> 
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
> 
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
> 
> Signed-off-by: MD Danish Anwar 
> ---
> Changes from v4 to v5:
> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>that can be loaded to a rproc.
> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
> *) Allocating the address at a later point in rproc_boot()
> *) Rebased on latest u-boot/master [commit 
>9e00b6993f724da9699ef12573307afea8c19284]
> 
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
> 
> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
> 
>  drivers/remoteproc/Kconfig|   8 +++
>  drivers/remoteproc/rproc-uclass.c | 100 ++
>  include/remoteproc.h  |  34 ++
>  3 files changed, 142 insertions(+)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..759d21437a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig

[...]

> +
> +free_buffer:
> + free(addr);

Thanks for taking care of freeing the memory.
Acked-by: Ravi Gunasekaran 

[...]

-- 
Regards,
Ravi