[PATCH 0/2] MediaTek SCP: Urgent fixes for all MTK SoCs

[PATCH 0/2] MediaTek SCP: Urgent fixes for all MTK SoCs

[AngeloGioacchino Del Regno]

This series brings some missing validation for the IPI buffer size
that is read from the firmware retrieved from userspace: if the FW
declares IPI buffer offset starting at an out of range address, the
driver doesn't do any validation and naively goes on with IO R/W
operation.

That poses various risks which I believe I really don't need to
describe, leaving it to the reader's imagination :-)

Please note that the first fix is URGENT.

P.S.: Of course, this was tested OK on multiple MTK platforms.

AngeloGioacchino Del Regno (2):
  remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
  remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

 drivers/remoteproc/mtk_scp.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
2.44.0

[PATCH 0/2] MediaTek SCP: Urgent fixes for all MTK SoCs

[AngeloGioacchino Del Regno]

This series brings some missing validation for the IPI buffer size
that is read from the firmware retrieved from userspace: if the FW
declares IPI buffer offset starting at an out of range address, the
driver doesn't do any validation and naively goes on with IO R/W
operation.

That poses various risks which I believe I really don't need to
describe, leaving it to the reader's imagination :-)

Please note that the first fix is URGENT.

P.S.: Of course, this was tested OK on multiple MTK platforms.

AngeloGioacchino Del Regno (2):
  remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
  remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

 drivers/remoteproc/mtk_scp.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

-- 
2.44.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[AngeloGioacchino Del Regno]

The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.

Failing to perform this check may make this driver perform R/W
oeprations out of the L2TCM boundary, resulting (at best) in a
kernel panic.

To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core).

Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/remoteproc/mtk_scp.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index a35409eda0cf..67518291a8ad 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -132,7 +132,7 @@ static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
 static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
 {
 	int ret;
-	size_t offset;
+	size_t buf_sz, offset;
 
 	/* read the ipi buf addr from FW itself first */
 	ret = scp_elf_read_ipi_buf_addr(scp, fw, &offset);
@@ -144,6 +144,14 @@ static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
 	}
 	dev_info(scp->dev, "IPI buf addr %#010zx\n", offset);
 
+	/* Make sure IPI buffer fits in the L2TCM range assigned to this core */
+	buf_sz = sizeof(*scp->recv_buf) + sizeof(*scp->send_buf);
+
+	if (scp->sram_size < buf_sz + offset) {
+		dev_err(scp->dev, "IPI buffer does not fit in SRAM.\n");
+		return -EOVERFLOW;
+	}
+
 	scp->recv_buf = (struct mtk_share_obj __iomem *)
 			(scp->sram_base + offset);
 	scp->send_buf = (struct mtk_share_obj __iomem *)
-- 
2.44.0

[PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[AngeloGioacchino Del Regno]

The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.

Failing to perform this check may make this driver perform R/W
oeprations out of the L2TCM boundary, resulting (at best) in a
kernel panic.

To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core).

Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/remoteproc/mtk_scp.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index a35409eda0cf..67518291a8ad 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -132,7 +132,7 @@ static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
 static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
 {
 	int ret;
-	size_t offset;
+	size_t buf_sz, offset;
 
 	/* read the ipi buf addr from FW itself first */
 	ret = scp_elf_read_ipi_buf_addr(scp, fw, &offset);
@@ -144,6 +144,14 @@ static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
 	}
 	dev_info(scp->dev, "IPI buf addr %#010zx\n", offset);
 
+	/* Make sure IPI buffer fits in the L2TCM range assigned to this core */
+	buf_sz = sizeof(*scp->recv_buf) + sizeof(*scp->send_buf);
+
+	if (scp->sram_size < buf_sz + offset) {
+		dev_err(scp->dev, "IPI buffer does not fit in SRAM.\n");
+		return -EOVERFLOW;
+	}
+
 	scp->recv_buf = (struct mtk_share_obj __iomem *)
 			(scp->sram_base + offset);
 	scp->send_buf = (struct mtk_share_obj __iomem *)
-- 
2.44.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

When probing multi-core SCP, this driver is parsing all sub-nodes of
the scp-cluster node, but one of those could be not an actual SCP core
and that would make the entire SCP cluster to fail probing for no good
reason.

To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
parsing only available subnodes having compatible "mediatek,scp-core".

Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/remoteproc/mtk_scp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 67518291a8ad..fbe1c232dae7 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
 	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
 
 	for_each_available_child_of_node(np, child) {
+		if (!of_device_is_compatible(child, "mediatek,scp-core"))
+			continue;
+
 		if (!cluster_of_data[core_id]) {
 			ret = -EINVAL;
 			dev_err(dev, "Not support core %d\n", core_id);
-- 
2.44.0

[PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

When probing multi-core SCP, this driver is parsing all sub-nodes of
the scp-cluster node, but one of those could be not an actual SCP core
and that would make the entire SCP cluster to fail probing for no good
reason.

To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
parsing only available subnodes having compatible "mediatek,scp-core".

Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/remoteproc/mtk_scp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 67518291a8ad..fbe1c232dae7 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
 	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
 
 	for_each_available_child_of_node(np, child) {
+		if (!of_device_is_compatible(child, "mediatek,scp-core"))
+			continue;
+
 		if (!cluster_of_data[core_id]) {
 			ret = -EINVAL;
 			dev_err(dev, "Not support core %d\n", core_id);
-- 
2.44.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[Mathieu Poirier]

Good day,

On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
> for that, and while this is especially true for multi-core SCP, it's
> still useful to check on single-core variants as well.
> 
> Failing to perform this check may make this driver perform R/W
> oeprations out of the L2TCM boundary, resulting (at best) in a

s/oeprations/operations

I will fix that when I apply the patch.

> kernel panic.
> 
> To fix that, check that the IPI buffer fits, otherwise return a
> failure and refuse to boot the relevant SCP core (or the SCP at
> all, if this is single core).
> 
> Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/remoteproc/mtk_scp.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index a35409eda0cf..67518291a8ad 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -132,7 +132,7 @@ static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
>  static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
>  {
>  	int ret;
> -	size_t offset;
> +	size_t buf_sz, offset;
>  
>  	/* read the ipi buf addr from FW itself first */
>  	ret = scp_elf_read_ipi_buf_addr(scp, fw, &offset);
> @@ -144,6 +144,14 @@ static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
>  	}
>  	dev_info(scp->dev, "IPI buf addr %#010zx\n", offset);
>  
> +	/* Make sure IPI buffer fits in the L2TCM range assigned to this core */
> +	buf_sz = sizeof(*scp->recv_buf) + sizeof(*scp->send_buf);
> +
> +	if (scp->sram_size < buf_sz + offset) {
> +		dev_err(scp->dev, "IPI buffer does not fit in SRAM.\n");
> +		return -EOVERFLOW;
> +	}
> +
>  	scp->recv_buf = (struct mtk_share_obj __iomem *)
>  			(scp->sram_base + offset);
>  	scp->send_buf = (struct mtk_share_obj __iomem *)
> -- 
> 2.44.0
> 

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[Mathieu Poirier]

Good day,

On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
> for that, and while this is especially true for multi-core SCP, it's
> still useful to check on single-core variants as well.
> 
> Failing to perform this check may make this driver perform R/W
> oeprations out of the L2TCM boundary, resulting (at best) in a

s/oeprations/operations

I will fix that when I apply the patch.

> kernel panic.
> 
> To fix that, check that the IPI buffer fits, otherwise return a
> failure and refuse to boot the relevant SCP core (or the SCP at
> all, if this is single core).
> 
> Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/remoteproc/mtk_scp.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index a35409eda0cf..67518291a8ad 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -132,7 +132,7 @@ static int scp_elf_read_ipi_buf_addr(struct mtk_scp *scp,
>  static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
>  {
>  	int ret;
> -	size_t offset;
> +	size_t buf_sz, offset;
>  
>  	/* read the ipi buf addr from FW itself first */
>  	ret = scp_elf_read_ipi_buf_addr(scp, fw, &offset);
> @@ -144,6 +144,14 @@ static int scp_ipi_init(struct mtk_scp *scp, const struct firmware *fw)
>  	}
>  	dev_info(scp->dev, "IPI buf addr %#010zx\n", offset);
>  
> +	/* Make sure IPI buffer fits in the L2TCM range assigned to this core */
> +	buf_sz = sizeof(*scp->recv_buf) + sizeof(*scp->send_buf);
> +
> +	if (scp->sram_size < buf_sz + offset) {
> +		dev_err(scp->dev, "IPI buffer does not fit in SRAM.\n");
> +		return -EOVERFLOW;
> +	}
> +
>  	scp->recv_buf = (struct mtk_share_obj __iomem *)
>  			(scp->sram_base + offset);
>  	scp->send_buf = (struct mtk_share_obj __iomem *)
> -- 
> 2.44.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> When probing multi-core SCP, this driver is parsing all sub-nodes of
> the scp-cluster node, but one of those could be not an actual SCP core
> and that would make the entire SCP cluster to fail probing for no good
> reason.
> 
> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> parsing only available subnodes having compatible "mediatek,scp-core".
> 
> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/remoteproc/mtk_scp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 67518291a8ad..fbe1c232dae7 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>  	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>  
>  	for_each_available_child_of_node(np, child) {
> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
> +			continue;
> +

Interesting - what else gets stashed under the remote processor node?  I don't
see anything specified in the bindings.

Thanks,
Mathieu

>  		if (!cluster_of_data[core_id]) {
>  			ret = -EINVAL;
>  			dev_err(dev, "Not support core %d\n", core_id);
> -- 
> 2.44.0
> 

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> When probing multi-core SCP, this driver is parsing all sub-nodes of
> the scp-cluster node, but one of those could be not an actual SCP core
> and that would make the entire SCP cluster to fail probing for no good
> reason.
> 
> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> parsing only available subnodes having compatible "mediatek,scp-core".
> 
> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  drivers/remoteproc/mtk_scp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> index 67518291a8ad..fbe1c232dae7 100644
> --- a/drivers/remoteproc/mtk_scp.c
> +++ b/drivers/remoteproc/mtk_scp.c
> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>  	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>  
>  	for_each_available_child_of_node(np, child) {
> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
> +			continue;
> +

Interesting - what else gets stashed under the remote processor node?  I don't
see anything specified in the bindings.

Thanks,
Mathieu

>  		if (!cluster_of_data[core_id]) {
>  			ret = -EINVAL;
>  			dev_err(dev, "Not support core %d\n", core_id);
> -- 
> 2.44.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[Tzung-Bi Shih]

On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
> for that, and while this is especially true for multi-core SCP, it's
> still useful to check on single-core variants as well.
> 
> Failing to perform this check may make this driver perform R/W
> oeprations out of the L2TCM boundary, resulting (at best) in a
> kernel panic.
> 
> To fix that, check that the IPI buffer fits, otherwise return a
> failure and refuse to boot the relevant SCP core (or the SCP at
> all, if this is single core).
> 
> Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[Tzung-Bi Shih]

On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
> The IPI buffer location is read from the firmware that we load to the
> System Companion Processor, and it's not granted that both the SRAM
> (L2TCM) size that is defined in the devicetree node is large enough
> for that, and while this is especially true for multi-core SCP, it's
> still useful to check on single-core variants as well.
> 
> Failing to perform this check may make this driver perform R/W
> oeprations out of the L2TCM boundary, resulting (at best) in a
> kernel panic.
> 
> To fix that, check that the IPI buffer fits, otherwise return a
> failure and refuse to boot the relevant SCP core (or the SCP at
> all, if this is single core).
> 
> Fixes: 3efa0ea743b7 ("remoteproc/mediatek: read IPI buffer offset from FW")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[AngeloGioacchino Del Regno]

Il 21/03/24 16:25, Mathieu Poirier ha scritto:
> Good day,
> 
> On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
>> The IPI buffer location is read from the firmware that we load to the
>> System Companion Processor, and it's not granted that both the SRAM
>> (L2TCM) size that is defined in the devicetree node is large enough
>> for that, and while this is especially true for multi-core SCP, it's
>> still useful to check on single-core variants as well.
>>
>> Failing to perform this check may make this driver perform R/W
>> oeprations out of the L2TCM boundary, resulting (at best) in a
> 
> s/oeprations/operations
> 
> I will fix that when I apply the patch.
> 

Thanks for that.

Cheers,
Angelo

Re: [PATCH 1/2] remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

[AngeloGioacchino Del Regno]

Il 21/03/24 16:25, Mathieu Poirier ha scritto:
> Good day,
> 
> On Thu, Mar 21, 2024 at 09:46:13AM +0100, AngeloGioacchino Del Regno wrote:
>> The IPI buffer location is read from the firmware that we load to the
>> System Companion Processor, and it's not granted that both the SRAM
>> (L2TCM) size that is defined in the devicetree node is large enough
>> for that, and while this is especially true for multi-core SCP, it's
>> still useful to check on single-core variants as well.
>>
>> Failing to perform this check may make this driver perform R/W
>> oeprations out of the L2TCM boundary, resulting (at best) in a
> 
> s/oeprations/operations
> 
> I will fix that when I apply the patch.
> 

Thanks for that.

Cheers,
Angelo



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>> the scp-cluster node, but one of those could be not an actual SCP core
>> and that would make the entire SCP cluster to fail probing for no good
>> reason.
>>
>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>> parsing only available subnodes having compatible "mediatek,scp-core".
>>
>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/remoteproc/mtk_scp.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>> index 67518291a8ad..fbe1c232dae7 100644
>> --- a/drivers/remoteproc/mtk_scp.c
>> +++ b/drivers/remoteproc/mtk_scp.c
>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>   	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>   
>>   	for_each_available_child_of_node(np, child) {
>> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
>> +			continue;
>> +
> 
> Interesting - what else gets stashed under the remote processor node?  I don't
> see anything specified in the bindings.
> 

Sorry for the late reply - well, in this precise moment in time, upstream,
nothing yet.

I have noticed this while debugging some lockups and wanted to move the scp_adsp
clock controller node as child of the SCP node (as some of those clocks are located
*into the SCP's CFG register space*, and it's correct for that to be a child as one
of those do depend on the SCP being up - and I'll spare you the rest) and noticed
the unexpected behavior, as the SCP driver was treating those as an SCP core.

There was no kernel panic, but the SCP would fail probing.

This is anyway a missed requirement ... for platforms that want *both* two SCP
cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
(scp@1072000, clock-controller@1072000), other than the reasons I explained some
lines back.

...and that's why this commit was sent :-)

P.S.: The reason why platforms don't crash without the scp_adsp clock controller
       as a child of SCP is that the bootloader is actually doing basic init for
       the SCP, hence the block is powered on when booting ;-)

Cheers,
Angelo

> Thanks,
> Mathieu
> 
>>   		if (!cluster_of_data[core_id]) {
>>   			ret = -EINVAL;
>>   			dev_err(dev, "Not support core %d\n", core_id);
>> -- 
>> 2.44.0
>>

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>> the scp-cluster node, but one of those could be not an actual SCP core
>> and that would make the entire SCP cluster to fail probing for no good
>> reason.
>>
>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>> parsing only available subnodes having compatible "mediatek,scp-core".
>>
>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/remoteproc/mtk_scp.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>> index 67518291a8ad..fbe1c232dae7 100644
>> --- a/drivers/remoteproc/mtk_scp.c
>> +++ b/drivers/remoteproc/mtk_scp.c
>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>   	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>   
>>   	for_each_available_child_of_node(np, child) {
>> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
>> +			continue;
>> +
> 
> Interesting - what else gets stashed under the remote processor node?  I don't
> see anything specified in the bindings.
> 

Sorry for the late reply - well, in this precise moment in time, upstream,
nothing yet.

I have noticed this while debugging some lockups and wanted to move the scp_adsp
clock controller node as child of the SCP node (as some of those clocks are located
*into the SCP's CFG register space*, and it's correct for that to be a child as one
of those do depend on the SCP being up - and I'll spare you the rest) and noticed
the unexpected behavior, as the SCP driver was treating those as an SCP core.

There was no kernel panic, but the SCP would fail probing.

This is anyway a missed requirement ... for platforms that want *both* two SCP
cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
(scp@1072000, clock-controller@1072000), other than the reasons I explained some
lines back.

...and that's why this commit was sent :-)

P.S.: The reason why platforms don't crash without the scp_adsp clock controller
       as a child of SCP is that the bootloader is actually doing basic init for
       the SCP, hence the block is powered on when booting ;-)

Cheers,
Angelo

> Thanks,
> Mathieu
> 
>>   		if (!cluster_of_data[core_id]) {
>>   			ret = -EINVAL;
>>   			dev_err(dev, "Not support core %d\n", core_id);
>> -- 
>> 2.44.0
>>



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> > On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> > > When probing multi-core SCP, this driver is parsing all sub-nodes of
> > > the scp-cluster node, but one of those could be not an actual SCP core
> > > and that would make the entire SCP cluster to fail probing for no good
> > > reason.
> > > 
> > > To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> > > parsing only available subnodes having compatible "mediatek,scp-core".
> > > 
> > > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > >   drivers/remoteproc/mtk_scp.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> > > index 67518291a8ad..fbe1c232dae7 100644
> > > --- a/drivers/remoteproc/mtk_scp.c
> > > +++ b/drivers/remoteproc/mtk_scp.c
> > > @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> > >   	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> > >   	for_each_available_child_of_node(np, child) {
> > > +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
> > > +			continue;
> > > +
> > 
> > Interesting - what else gets stashed under the remote processor node?  I don't
> > see anything specified in the bindings.
> > 
> 
> Sorry for the late reply - well, in this precise moment in time, upstream,
> nothing yet.
> 
> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> clock controller node as child of the SCP node (as some of those clocks are located
> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> the unexpected behavior, as the SCP driver was treating those as an SCP core.
> 
> There was no kernel panic, but the SCP would fail probing.
> 
> This is anyway a missed requirement ... for platforms that want *both* two SCP
> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> lines back.
> 
> ...and that's why this commit was sent :-)
>

Please update the bindings with the extra clock requirement in your next
revision. 

> P.S.: The reason why platforms don't crash without the scp_adsp clock controller
>       as a child of SCP is that the bootloader is actually doing basic init for
>       the SCP, hence the block is powered on when booting ;-)
> 
> Cheers,
> Angelo
> 
> > Thanks,
> > Mathieu
> > 
> > >   		if (!cluster_of_data[core_id]) {
> > >   			ret = -EINVAL;
> > >   			dev_err(dev, "Not support core %d\n", core_id);
> > > -- 
> > > 2.44.0
> > > 
> 
> 

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> > On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> > > When probing multi-core SCP, this driver is parsing all sub-nodes of
> > > the scp-cluster node, but one of those could be not an actual SCP core
> > > and that would make the entire SCP cluster to fail probing for no good
> > > reason.
> > > 
> > > To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> > > parsing only available subnodes having compatible "mediatek,scp-core".
> > > 
> > > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > >   drivers/remoteproc/mtk_scp.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> > > index 67518291a8ad..fbe1c232dae7 100644
> > > --- a/drivers/remoteproc/mtk_scp.c
> > > +++ b/drivers/remoteproc/mtk_scp.c
> > > @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> > >   	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> > >   	for_each_available_child_of_node(np, child) {
> > > +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
> > > +			continue;
> > > +
> > 
> > Interesting - what else gets stashed under the remote processor node?  I don't
> > see anything specified in the bindings.
> > 
> 
> Sorry for the late reply - well, in this precise moment in time, upstream,
> nothing yet.
> 
> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> clock controller node as child of the SCP node (as some of those clocks are located
> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> the unexpected behavior, as the SCP driver was treating those as an SCP core.
> 
> There was no kernel panic, but the SCP would fail probing.
> 
> This is anyway a missed requirement ... for platforms that want *both* two SCP
> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> lines back.
> 
> ...and that's why this commit was sent :-)
>

Please update the bindings with the extra clock requirement in your next
revision. 

> P.S.: The reason why platforms don't crash without the scp_adsp clock controller
>       as a child of SCP is that the bootloader is actually doing basic init for
>       the SCP, hence the block is powered on when booting ;-)
> 
> Cheers,
> Angelo
> 
> > Thanks,
> > Mathieu
> > 
> > >   		if (!cluster_of_data[core_id]) {
> > >   			ret = -EINVAL;
> > >   			dev_err(dev, "Not support core %d\n", core_id);
> > > -- 
> > > 2.44.0
> > > 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
>> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
>>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>>>> the scp-cluster node, but one of those could be not an actual SCP core
>>>> and that would make the entire SCP cluster to fail probing for no good
>>>> reason.
>>>>
>>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>>>> parsing only available subnodes having compatible "mediatek,scp-core".
>>>>
>>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>> ---
>>>>    drivers/remoteproc/mtk_scp.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>>>> index 67518291a8ad..fbe1c232dae7 100644
>>>> --- a/drivers/remoteproc/mtk_scp.c
>>>> +++ b/drivers/remoteproc/mtk_scp.c
>>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>>>    	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>>>    	for_each_available_child_of_node(np, child) {
>>>> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
>>>> +			continue;
>>>> +
>>>
>>> Interesting - what else gets stashed under the remote processor node?  I don't
>>> see anything specified in the bindings.
>>>
>>
>> Sorry for the late reply - well, in this precise moment in time, upstream,
>> nothing yet.
>>
>> I have noticed this while debugging some lockups and wanted to move the scp_adsp
>> clock controller node as child of the SCP node (as some of those clocks are located
>> *into the SCP's CFG register space*, and it's correct for that to be a child as one
>> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
>> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>>
>> There was no kernel panic, but the SCP would fail probing.
>>
>> This is anyway a missed requirement ... for platforms that want *both* two SCP
>> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
>> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
>> lines back.
>>
>> ...and that's why this commit was sent :-)
>>
> 
> Please update the bindings with the extra clock requirement in your next
> revision.
> 

Ok.

Can you please take only patch 1/2 of this series so that I can delay this one
for a bit? I don't have time to work on that exactly right now.

Thanks,
Angelo

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
>> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
>>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>>>> the scp-cluster node, but one of those could be not an actual SCP core
>>>> and that would make the entire SCP cluster to fail probing for no good
>>>> reason.
>>>>
>>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>>>> parsing only available subnodes having compatible "mediatek,scp-core".
>>>>
>>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>> ---
>>>>    drivers/remoteproc/mtk_scp.c | 3 +++
>>>>    1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>>>> index 67518291a8ad..fbe1c232dae7 100644
>>>> --- a/drivers/remoteproc/mtk_scp.c
>>>> +++ b/drivers/remoteproc/mtk_scp.c
>>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>>>    	cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>>>    	for_each_available_child_of_node(np, child) {
>>>> +		if (!of_device_is_compatible(child, "mediatek,scp-core"))
>>>> +			continue;
>>>> +
>>>
>>> Interesting - what else gets stashed under the remote processor node?  I don't
>>> see anything specified in the bindings.
>>>
>>
>> Sorry for the late reply - well, in this precise moment in time, upstream,
>> nothing yet.
>>
>> I have noticed this while debugging some lockups and wanted to move the scp_adsp
>> clock controller node as child of the SCP node (as some of those clocks are located
>> *into the SCP's CFG register space*, and it's correct for that to be a child as one
>> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
>> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>>
>> There was no kernel panic, but the SCP would fail probing.
>>
>> This is anyway a missed requirement ... for platforms that want *both* two SCP
>> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
>> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
>> lines back.
>>
>> ...and that's why this commit was sent :-)
>>
> 
> Please update the bindings with the extra clock requirement in your next
> revision.
> 

Ok.

Can you please take only patch 1/2 of this series so that I can delay this one
for a bit? I don't have time to work on that exactly right now.

Thanks,
Angelo



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> > On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> >> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> >>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> >>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
> >>>> the scp-cluster node, but one of those could be not an actual SCP core
> >>>> and that would make the entire SCP cluster to fail probing for no good
> >>>> reason.
> >>>>
> >>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> >>>> parsing only available subnodes having compatible "mediatek,scp-core".
> >>>>
> >>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> >>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> >>>> ---
> >>>>    drivers/remoteproc/mtk_scp.c | 3 +++
> >>>>    1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> >>>> index 67518291a8ad..fbe1c232dae7 100644
> >>>> --- a/drivers/remoteproc/mtk_scp.c
> >>>> +++ b/drivers/remoteproc/mtk_scp.c
> >>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> >>>>            cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> >>>>            for_each_available_child_of_node(np, child) {
> >>>> +          if (!of_device_is_compatible(child, "mediatek,scp-core"))
> >>>> +                  continue;
> >>>> +
> >>>
> >>> Interesting - what else gets stashed under the remote processor node?  I don't
> >>> see anything specified in the bindings.
> >>>
> >>
> >> Sorry for the late reply - well, in this precise moment in time, upstream,
> >> nothing yet.
> >>
> >> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> >> clock controller node as child of the SCP node (as some of those clocks are located
> >> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> >> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> >> the unexpected behavior, as the SCP driver was treating those as an SCP core.
> >>
> >> There was no kernel panic, but the SCP would fail probing.
> >>
> >> This is anyway a missed requirement ... for platforms that want *both* two SCP
> >> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> >> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> >> lines back.
> >>
> >> ...and that's why this commit was sent :-)
> >>
> >
> > Please update the bindings with the extra clock requirement in your next
> > revision.
> >
>
> Ok.
>
> Can you please take only patch 1/2 of this series so that I can delay this one
> for a bit? I don't have time to work on that exactly right now.
>

It was added to rproc-next last week.

> Thanks,
> Angelo
>
>

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[Mathieu Poirier]

On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
> > On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> >> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> >>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> >>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
> >>>> the scp-cluster node, but one of those could be not an actual SCP core
> >>>> and that would make the entire SCP cluster to fail probing for no good
> >>>> reason.
> >>>>
> >>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> >>>> parsing only available subnodes having compatible "mediatek,scp-core".
> >>>>
> >>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> >>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> >>>> ---
> >>>>    drivers/remoteproc/mtk_scp.c | 3 +++
> >>>>    1 file changed, 3 insertions(+)
> >>>>
> >>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> >>>> index 67518291a8ad..fbe1c232dae7 100644
> >>>> --- a/drivers/remoteproc/mtk_scp.c
> >>>> +++ b/drivers/remoteproc/mtk_scp.c
> >>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> >>>>            cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> >>>>            for_each_available_child_of_node(np, child) {
> >>>> +          if (!of_device_is_compatible(child, "mediatek,scp-core"))
> >>>> +                  continue;
> >>>> +
> >>>
> >>> Interesting - what else gets stashed under the remote processor node?  I don't
> >>> see anything specified in the bindings.
> >>>
> >>
> >> Sorry for the late reply - well, in this precise moment in time, upstream,
> >> nothing yet.
> >>
> >> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> >> clock controller node as child of the SCP node (as some of those clocks are located
> >> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> >> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> >> the unexpected behavior, as the SCP driver was treating those as an SCP core.
> >>
> >> There was no kernel panic, but the SCP would fail probing.
> >>
> >> This is anyway a missed requirement ... for platforms that want *both* two SCP
> >> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> >> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> >> lines back.
> >>
> >> ...and that's why this commit was sent :-)
> >>
> >
> > Please update the bindings with the extra clock requirement in your next
> > revision.
> >
>
> Ok.
>
> Can you please take only patch 1/2 of this series so that I can delay this one
> for a bit? I don't have time to work on that exactly right now.
>

It was added to rproc-next last week.

> Thanks,
> Angelo
>
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 02/04/24 16:23, Mathieu Poirier ha scritto:
> On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
>>> On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
>>>>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>>>>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>>>>>> the scp-cluster node, but one of those could be not an actual SCP core
>>>>>> and that would make the entire SCP cluster to fail probing for no good
>>>>>> reason.
>>>>>>
>>>>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>>>>>> parsing only available subnodes having compatible "mediatek,scp-core".
>>>>>>
>>>>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>>>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>>>> ---
>>>>>>     drivers/remoteproc/mtk_scp.c | 3 +++
>>>>>>     1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>>>>>> index 67518291a8ad..fbe1c232dae7 100644
>>>>>> --- a/drivers/remoteproc/mtk_scp.c
>>>>>> +++ b/drivers/remoteproc/mtk_scp.c
>>>>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>>>>>             cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>>>>>             for_each_available_child_of_node(np, child) {
>>>>>> +          if (!of_device_is_compatible(child, "mediatek,scp-core"))
>>>>>> +                  continue;
>>>>>> +
>>>>>
>>>>> Interesting - what else gets stashed under the remote processor node?  I don't
>>>>> see anything specified in the bindings.
>>>>>
>>>>
>>>> Sorry for the late reply - well, in this precise moment in time, upstream,
>>>> nothing yet.
>>>>
>>>> I have noticed this while debugging some lockups and wanted to move the scp_adsp
>>>> clock controller node as child of the SCP node (as some of those clocks are located
>>>> *into the SCP's CFG register space*, and it's correct for that to be a child as one
>>>> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
>>>> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>>>>
>>>> There was no kernel panic, but the SCP would fail probing.
>>>>
>>>> This is anyway a missed requirement ... for platforms that want *both* two SCP
>>>> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
>>>> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
>>>> lines back.
>>>>
>>>> ...and that's why this commit was sent :-)
>>>>
>>>
>>> Please update the bindings with the extra clock requirement in your next
>>> revision.
>>>
>>
>> Ok.
>>
>> Can you please take only patch 1/2 of this series so that I can delay this one
>> for a bit? I don't have time to work on that exactly right now.
>>
> 
> It was added to rproc-next last week.
> 

Ah, sorry, didn't notice that.

Thanks again!

Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core

[AngeloGioacchino Del Regno]

Il 02/04/24 16:23, Mathieu Poirier ha scritto:
> On Tue, 2 Apr 2024 at 03:56, AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 28/03/24 15:38, Mathieu Poirier ha scritto:
>>> On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
>>>>> On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
>>>>>> When probing multi-core SCP, this driver is parsing all sub-nodes of
>>>>>> the scp-cluster node, but one of those could be not an actual SCP core
>>>>>> and that would make the entire SCP cluster to fail probing for no good
>>>>>> reason.
>>>>>>
>>>>>> To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
>>>>>> parsing only available subnodes having compatible "mediatek,scp-core".
>>>>>>
>>>>>> Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
>>>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>>>> ---
>>>>>>     drivers/remoteproc/mtk_scp.c | 3 +++
>>>>>>     1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
>>>>>> index 67518291a8ad..fbe1c232dae7 100644
>>>>>> --- a/drivers/remoteproc/mtk_scp.c
>>>>>> +++ b/drivers/remoteproc/mtk_scp.c
>>>>>> @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
>>>>>>             cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
>>>>>>             for_each_available_child_of_node(np, child) {
>>>>>> +          if (!of_device_is_compatible(child, "mediatek,scp-core"))
>>>>>> +                  continue;
>>>>>> +
>>>>>
>>>>> Interesting - what else gets stashed under the remote processor node?  I don't
>>>>> see anything specified in the bindings.
>>>>>
>>>>
>>>> Sorry for the late reply - well, in this precise moment in time, upstream,
>>>> nothing yet.
>>>>
>>>> I have noticed this while debugging some lockups and wanted to move the scp_adsp
>>>> clock controller node as child of the SCP node (as some of those clocks are located
>>>> *into the SCP's CFG register space*, and it's correct for that to be a child as one
>>>> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
>>>> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>>>>
>>>> There was no kernel panic, but the SCP would fail probing.
>>>>
>>>> This is anyway a missed requirement ... for platforms that want *both* two SCP
>>>> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
>>>> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
>>>> lines back.
>>>>
>>>> ...and that's why this commit was sent :-)
>>>>
>>>
>>> Please update the bindings with the extra clock requirement in your next
>>> revision.
>>>
>>
>> Ok.
>>
>> Can you please take only patch 1/2 of this series so that I can delay this one
>> for a bit? I don't have time to work on that exactly right now.
>>
> 
> It was added to rproc-next last week.
> 

Ah, sorry, didn't notice that.

Thanks again!



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel