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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b6ed8710-1608-4343-8a58-5f8e0e16d10d@collabora.com>
Date: Tue, 2 Apr 2024 11:56:40 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: andersson@...nel.org, matthias.bgg@...il.com, tzungbi@...nel.org,
 tinghan.shen@...iatek.com, linux-remoteproc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, wenst@...omium.org, kernel@...labora.com
Subject: Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes
 for multi-core

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@...labora.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@...2000, clock-controller@...2000), 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