linux-kernel - [PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property

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-next>] [day] [month] [year] [list]

Message-ID: <20230919050305.3817347-1-wenst@chromium.org>
Date:   Tue, 19 Sep 2023 13:03:04 +0800
From:   Chen-Yu Tsai <wenst@...omium.org>
To:     Bjorn Andersson <andersson@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Cc:     Chen-Yu Tsai <wenst@...omium.org>,
        Tinghan Shen <tinghan.shen@...iatek.com>,
        linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Laura Nao <laura.nao@...labora.com>
Subject: [PATCH] remoteproc: mediatek: Detect single/multi core SCP with rpmsg-name property

In the just landed multi-core SCP work, detection of single/multi core
SCP is done by checking the immediate child node of the SCP complex
device node. In the original work this was done by matching the child
node's name. However the name wasn't previously standardized. This
resulted in breakage on MT8183 and MT8192 Chromebooks while the driver
side changes were picked up and the device tree changes were not picked
up.

Instead, match against the "mediatek,rpmsg-name" property, which is
required to be present in the rpmsg sub-node. This makes the
aforementioned devices running old device trees working again.

Reported-by: Laura Nao <laura.nao@...labora.com>
Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
Signed-off-by: Chen-Yu Tsai <wenst@...omium.org>
---
The patch is based on next-20230918 with a whole bunch of local patches
stacked on top. None of my local patches are related to remoteproc, so
it should be fine.

I tested on both MT8183 Juniper and MT8192 Hayato and on both systems
the SCP successfully probed again.

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

diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ea227b566c54..ca15d9f382a1 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1149,13 +1149,23 @@ static int scp_is_single_core(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev_of_node(dev);
 	struct device_node *child;
+	bool has_rpmsg;
 
 	child = of_get_next_available_child(np, NULL);
 	if (!child)
 		return dev_err_probe(dev, -ENODEV, "No child node\n");
 
+	/*
+	 * On single core SCP systems, the immediate child of the SCP device
+	 * is the rpmsg node; on multi core systems, there's an intermediate
+	 * level node, one describing each core. Instead of matching on the
+	 * node name, which was recently changed in the DT binding in a
+	 * backward incompatible way, match against the "mediatek,rpmsg-name"
+	 * property, which is required in all rpmsg sub-nodes.
+	 */
+	has_rpmsg = of_property_present(child, "mediatek,rpmsg-name");
 	of_node_put(child);
-	return of_node_name_eq(child, "cros-ec-rpmsg");
+	return has_rpmsg;
 }
 
 static int scp_cluster_init(struct platform_device *pdev, struct mtk_scp_of_cluster *scp_cluster)
-- 
2.42.0.459.ge4e396fd5e-goog