[PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Suman Anna]

Hi Bjorn,

This is another minor revision of the fixes around fixed memory region
support [1] series. Patch 1 is revised to go back to the logic used in v1
after a long discussion on the v2 version [2]. The other suggestions can
be future improvments as they would require corresponding platform driver
changes. Please look through the discussion there and let us know your
preference. Patches are based on v5.7-rc1.

I really appreciate it if you can target the series for the current 5.7 -rc's.
The fixes would apply for all 5.1+ kernels.

Please see the v1 cover-letter [1] for the details on the issues.

regards
Suman

[1] https://patchwork.kernel.org/cover/11422723/
[2] https://patchwork.kernel.org/comment/23274389/

Suman Anna (1):
  remoteproc: Fix and restore the parenting hierarchy for vdev

Tero Kristo (1):
  remoteproc: Fall back to using parent memory pool if no dedicated
    available

 drivers/remoteproc/remoteproc_core.c   |  2 +-
 drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

-- 
2.26.0

[PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Suman Anna]

Hi Bjorn,

This is another minor revision of the fixes around fixed memory region
support [1] series. Patch 1 is revised to go back to the logic used in v1
after a long discussion on the v2 version [2]. The other suggestions can
be future improvments as they would require corresponding platform driver
changes. Please look through the discussion there and let us know your
preference. Patches are based on v5.7-rc1.

I really appreciate it if you can target the series for the current 5.7 -rc's.
The fixes would apply for all 5.1+ kernels.

Please see the v1 cover-letter [1] for the details on the issues.

regards
Suman

[1] https://patchwork.kernel.org/cover/11422723/
[2] https://patchwork.kernel.org/comment/23274389/

Suman Anna (1):
  remoteproc: Fix and restore the parenting hierarchy for vdev

Tero Kristo (1):
  remoteproc: Fall back to using parent memory pool if no dedicated
    available

 drivers/remoteproc/remoteproc_core.c   |  2 +-
 drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
 2 files changed, 13 insertions(+), 1 deletion(-)

-- 
2.26.0

[PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available

[Suman Anna]

From: Tero Kristo <t-kristo@ti.com>

In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v3:
 - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
 - Revised the comment to remove references to vdevbuf_mem_id
 - Capitalize the patch header
v2: https://patchwork.kernel.org/patch/11447651/

 drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index e61d738d9b47..44187fe43677 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
 				goto out;
 			}
 		}
+	} else {
+		struct device_node *np = rproc->dev.parent->of_node;
+
+		/*
+		 * If we don't have dedicated buffer, just attempt to re-assign
+		 * the reserved memory from our parent. A default memory-region
+		 * at index 0 from the parent's memory-regions is assigned for
+		 * the rvdev dev to allocate from. Failure is non-critical and
+		 * the allocations will fall back to global pools, so don't
+		 * check return value either.
+		 */
+		of_reserved_mem_device_init_by_idx(dev, np, 0);
 	}
 
 	/* Allocate virtio device */
-- 
2.26.0

[PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available

[Suman Anna]

From: Tero Kristo <t-kristo@ti.com>

In some cases, like with OMAP remoteproc, we are not creating dedicated
memory pool for the virtio device. Instead, we use the same memory pool
for all shared memories. The current virtio memory pool handling forces
a split between these two, as a separate device is created for it,
causing memory to be allocated from bad location if the dedicated pool
is not available. Fix this by falling back to using the parent device
memory pool if dedicated is not available.

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v3:
 - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
 - Revised the comment to remove references to vdevbuf_mem_id
 - Capitalize the patch header
v2: https://patchwork.kernel.org/patch/11447651/

 drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
index e61d738d9b47..44187fe43677 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
 				goto out;
 			}
 		}
+	} else {
+		struct device_node *np = rproc->dev.parent->of_node;
+
+		/*
+		 * If we don't have dedicated buffer, just attempt to re-assign
+		 * the reserved memory from our parent. A default memory-region
+		 * at index 0 from the parent's memory-regions is assigned for
+		 * the rvdev dev to allocate from. Failure is non-critical and
+		 * the allocations will fall back to global pools, so don't
+		 * check return value either.
+		 */
+		of_reserved_mem_device_init_by_idx(dev, np, 0);
 	}
 
 	/* Allocate virtio device */
-- 
2.26.0

[PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev

[Suman Anna]

The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.

Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
v3: No changes
v2: https://patchwork.kernel.org/patch/11447653/

 drivers/remoteproc/remoteproc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index e12a54e67588..be15aace9b3c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -517,7 +517,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
 
 	/* Initialise vdev subdevice */
 	snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
-	rvdev->dev.parent = rproc->dev.parent;
+	rvdev->dev.parent = &rproc->dev;
 	rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
 	rvdev->dev.release = rproc_rvdev_release;
 	dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);
-- 
2.26.0

[PATCH v3 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev

[Suman Anna]

The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
dma memory pool") has introduced a new vdev subdevice for each vdev
declared in the firmware resource table and made it as the parent for the
created virtio rpmsg devices instead of the previous remoteproc device.
This changed the overall parenting hierarchy for the rpmsg devices, which
were children of virtio devices, and does not allow the corresponding
rpmsg drivers to retrieve the parent rproc device through the
rproc_get_by_child() API.

Fix this by restoring the remoteproc device as the parent. The new vdev
subdevice can continue to inherit the DMA attributes from the remoteproc's
parent device (actual platform device).

Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
v3: No changes
v2: https://patchwork.kernel.org/patch/11447653/

 drivers/remoteproc/remoteproc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index e12a54e67588..be15aace9b3c 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -517,7 +517,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
 
 	/* Initialise vdev subdevice */
 	snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
-	rvdev->dev.parent = rproc->dev.parent;
+	rvdev->dev.parent = &rproc->dev;
 	rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
 	rvdev->dev.release = rproc_rvdev_release;
 	dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);
-- 
2.26.0

Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Suman Anna]

Hi Bjorn,

On 4/20/20 11:05 AM, Suman Anna wrote:
> Hi Bjorn,
> 
> This is another minor revision of the fixes around fixed memory region
> support [1] series. Patch 1 is revised to go back to the logic used in v1
> after a long discussion on the v2 version [2]. The other suggestions can
> be future improvments as they would require corresponding platform driver
> changes. Please look through the discussion there and let us know your
> preference. Patches are based on v5.7-rc1.
> 
> I really appreciate it if you can target the series for the current 5.7 -rc's.
> The fixes would apply for all 5.1+ kernels.

Ping on these.

regards
Suman

> 
> Please see the v1 cover-letter [1] for the details on the issues.
> 
> regards
> Suman
> 
> [1] https://patchwork.kernel.org/cover/11422723/
> [2] https://patchwork.kernel.org/comment/23274389/
> 
> Suman Anna (1):
>    remoteproc: Fix and restore the parenting hierarchy for vdev
> 
> Tero Kristo (1):
>    remoteproc: Fall back to using parent memory pool if no dedicated
>      available
> 
>   drivers/remoteproc/remoteproc_core.c   |  2 +-
>   drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>   2 files changed, 13 insertions(+), 1 deletion(-)
> 

Re: [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available

[Arnaud POULIQUEN]

Hi Suman

On 4/20/20 6:05 PM, Suman Anna wrote:
> From: Tero Kristo <t-kristo@ti.com>
> 
> In some cases, like with OMAP remoteproc, we are not creating dedicated
> memory pool for the virtio device. Instead, we use the same memory pool
> for all shared memories. The current virtio memory pool handling forces
> a split between these two, as a separate device is created for it,
> causing memory to be allocated from bad location if the dedicated pool
> is not available. Fix this by falling back to using the parent device
> memory pool if dedicated is not available.

As it fixes the implementation of the legacy, that seems reasonable to me.
 
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>

> 
> Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
> v3:
>  - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
>  - Revised the comment to remove references to vdevbuf_mem_id
>  - Capitalize the patch header
> v2: https://patchwork.kernel.org/patch/11447651/
> 
>  drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> index e61d738d9b47..44187fe43677 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>  				goto out;
>  			}
>  		}
> +	} else {
> +		struct device_node *np = rproc->dev.parent->of_node;
> +
> +		/*
> +		 * If we don't have dedicated buffer, just attempt to re-assign
> +		 * the reserved memory from our parent. A default memory-region
> +		 * at index 0 from the parent's memory-regions is assigned for
> +		 * the rvdev dev to allocate from. Failure is non-critical and
> +		 * the allocations will fall back to global pools, so don't
> +		 * check return value either.
> +		 */
> +		of_reserved_mem_device_init_by_idx(dev, np, 0);
>  	}
>  
>  	/* Allocate virtio device */
> 

Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Suman Anna]

Hi Bjorn,

On 5/2/20 1:29 PM, Suman Anna wrote:
> Hi Bjorn,
> 
> On 4/20/20 11:05 AM, Suman Anna wrote:
>> Hi Bjorn,
>>
>> This is another minor revision of the fixes around fixed memory region
>> support [1] series. Patch 1 is revised to go back to the logic used in v1
>> after a long discussion on the v2 version [2]. The other suggestions can
>> be future improvments as they would require corresponding platform driver
>> changes. Please look through the discussion there and let us know your
>> preference. Patches are based on v5.7-rc1.
>>
>> I really appreciate it if you can target the series for the current 
>> 5.7 -rc's.
>> The fixes would apply for all 5.1+ kernels.
> 
> Ping on these.

The patches have been reviewed and/or acked by both Mathieu and Arnaud.
Can you please get these into the current -rc's?

Thanks,
Suman

> 
> regards
> Suman
> 
>>
>> Please see the v1 cover-letter [1] for the details on the issues.
>>
>> regards
>> Suman
>>
>> [1] https://patchwork.kernel.org/cover/11422723/
>> [2] https://patchwork.kernel.org/comment/23274389/
>>
>> Suman Anna (1):
>>    remoteproc: Fix and restore the parenting hierarchy for vdev
>>
>> Tero Kristo (1):
>>    remoteproc: Fall back to using parent memory pool if no dedicated
>>      available
>>
>>   drivers/remoteproc/remoteproc_core.c   |  2 +-
>>   drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>>   2 files changed, 13 insertions(+), 1 deletion(-)
>>
> 

Re: [PATCH v3 1/2] remoteproc: Fall back to using parent memory pool if no dedicated available

[Mathieu Poirier]

On Mon, 20 Apr 2020 at 10:07, Suman Anna <s-anna@ti.com> wrote:
>
> From: Tero Kristo <t-kristo@ti.com>
>
> In some cases, like with OMAP remoteproc, we are not creating dedicated
> memory pool for the virtio device. Instead, we use the same memory pool
> for all shared memories. The current virtio memory pool handling forces
> a split between these two, as a separate device is created for it,
> causing memory to be allocated from bad location if the dedicated pool
> is not available. Fix this by falling back to using the parent device
> memory pool if dedicated is not available.
>
> Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Suman Anna <s-anna@ti.com>

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

>
> ---
> v3:
>  - Go back to v1 logic (removed the vdevbuf_mem_id variable added in v2)
>  - Revised the comment to remove references to vdevbuf_mem_id
>  - Capitalize the patch header
> v2: https://patchwork.kernel.org/patch/11447651/
>
>  drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_virtio.c b/drivers/remoteproc/remoteproc_virtio.c
> index e61d738d9b47..44187fe43677 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -376,6 +376,18 @@ int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>                                 goto out;
>                         }
>                 }
> +       } else {
> +               struct device_node *np = rproc->dev.parent->of_node;
> +
> +               /*
> +                * If we don't have dedicated buffer, just attempt to re-assign
> +                * the reserved memory from our parent. A default memory-region
> +                * at index 0 from the parent's memory-regions is assigned for
> +                * the rvdev dev to allocate from. Failure is non-critical and
> +                * the allocations will fall back to global pools, so don't
> +                * check return value either.
> +                */
> +               of_reserved_mem_device_init_by_idx(dev, np, 0);
>         }
>
>         /* Allocate virtio device */
> --
> 2.26.0
>

Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Bjorn Andersson]

On Fri 08 May 08:14 PDT 2020, Suman Anna wrote:

> Hi Bjorn,
> 
> On 5/2/20 1:29 PM, Suman Anna wrote:
> > Hi Bjorn,
> > 
> > On 4/20/20 11:05 AM, Suman Anna wrote:
> > > Hi Bjorn,
> > > 
> > > This is another minor revision of the fixes around fixed memory region
> > > support [1] series. Patch 1 is revised to go back to the logic used in v1
> > > after a long discussion on the v2 version [2]. The other suggestions can
> > > be future improvments as they would require corresponding platform driver
> > > changes. Please look through the discussion there and let us know your
> > > preference. Patches are based on v5.7-rc1.
> > > 
> > > I really appreciate it if you can target the series for the current
> > > 5.7 -rc's.
> > > The fixes would apply for all 5.1+ kernels.
> > 
> > Ping on these.
> 
> The patches have been reviewed and/or acked by both Mathieu and Arnaud.

Thanks for the reviews!

> Can you please get these into the current -rc's?
> 

The offending patch appeared in 5.1, so I have a hard time claiming that
this is a regression in 5.7-rc. I've added Cc: stable and picked the two
patches for 5.8.

Thanks,
Bjorn

> Thanks,
> Suman
> 
> > 
> > regards
> > Suman
> > 
> > > 
> > > Please see the v1 cover-letter [1] for the details on the issues.
> > > 
> > > regards
> > > Suman
> > > 
> > > [1] https://patchwork.kernel.org/cover/11422723/
> > > [2] https://patchwork.kernel.org/comment/23274389/
> > > 
> > > Suman Anna (1):
> > >    remoteproc: Fix and restore the parenting hierarchy for vdev
> > > 
> > > Tero Kristo (1):
> > >    remoteproc: Fall back to using parent memory pool if no dedicated
> > >      available
> > > 
> > >   drivers/remoteproc/remoteproc_core.c   |  2 +-
> > >   drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
> > >   2 files changed, 13 insertions(+), 1 deletion(-)
> > > 
> > 
> 

Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[patchwork-bot+linux-remoteproc]

Hello:

This series was applied to andersson/remoteproc.git (refs/heads/for-next).

On Mon, 20 Apr 2020 11:05:58 -0500 you wrote:
> Hi Bjorn,
> 
> This is another minor revision of the fixes around fixed memory region
> support [1] series. Patch 1 is revised to go back to the logic used in v1
> after a long discussion on the v2 version [2]. The other suggestions can
> be future improvments as they would require corresponding platform driver
> changes. Please look through the discussion there and let us know your
> preference. Patches are based on v5.7-rc1.
> 
> [...]


Here is a summary with links:
  - [v3,1/2] remoteproc: Fall back to using parent memory pool if no dedicated available
    https://git.kernel.org/andersson/remoteproc/c/db9178a4f8c4e523f824892cb8bab00961b07385
  - [v3,2/2] remoteproc: Fix and restore the parenting hierarchy for vdev
    https://git.kernel.org/andersson/remoteproc/c/c774ad010873bb89dcc0cdcb1e96aef6664d8caf

You are awesome, thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot

Re: [PATCH v3 0/2] Misc. rproc fixes around fixed memory region support

[Tero Kristo]

On 13/05/2020 02:10, Bjorn Andersson wrote:
> On Fri 08 May 08:14 PDT 2020, Suman Anna wrote:
> 
>> Hi Bjorn,
>>
>> On 5/2/20 1:29 PM, Suman Anna wrote:
>>> Hi Bjorn,
>>>
>>> On 4/20/20 11:05 AM, Suman Anna wrote:
>>>> Hi Bjorn,
>>>>
>>>> This is another minor revision of the fixes around fixed memory region
>>>> support [1] series. Patch 1 is revised to go back to the logic used in v1
>>>> after a long discussion on the v2 version [2]. The other suggestions can
>>>> be future improvments as they would require corresponding platform driver
>>>> changes. Please look through the discussion there and let us know your
>>>> preference. Patches are based on v5.7-rc1.
>>>>
>>>> I really appreciate it if you can target the series for the current
>>>> 5.7 -rc's.
>>>> The fixes would apply for all 5.1+ kernels.
>>>
>>> Ping on these.
>>
>> The patches have been reviewed and/or acked by both Mathieu and Arnaud.
> 
> Thanks for the reviews!
> 
>> Can you please get these into the current -rc's?
>>
> 
> The offending patch appeared in 5.1, so I have a hard time claiming that
> this is a regression in 5.7-rc. I've added Cc: stable and picked the two
> patches for 5.8.

Thanks Bjorn,

I believe 5.8 should be fine, we can backport this internally if needed.

-Tero

> 
> Thanks,
> Bjorn
> 
>> Thanks,
>> Suman
>>
>>>
>>> regards
>>> Suman
>>>
>>>>
>>>> Please see the v1 cover-letter [1] for the details on the issues.
>>>>
>>>> regards
>>>> Suman
>>>>
>>>> [1] https://patchwork.kernel.org/cover/11422723/
>>>> [2] https://patchwork.kernel.org/comment/23274389/
>>>>
>>>> Suman Anna (1):
>>>>     remoteproc: Fix and restore the parenting hierarchy for vdev
>>>>
>>>> Tero Kristo (1):
>>>>     remoteproc: Fall back to using parent memory pool if no dedicated
>>>>       available
>>>>
>>>>    drivers/remoteproc/remoteproc_core.c   |  2 +-
>>>>    drivers/remoteproc/remoteproc_virtio.c | 12 ++++++++++++
>>>>    2 files changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>
>>

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki