From nobody Fri Sep 20 11:39:45 2024 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45009C197A0 for ; Fri, 17 Nov 2023 09:42:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345790AbjKQJmu (ORCPT ); Fri, 17 Nov 2023 04:42:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345747AbjKQJmn (ORCPT ); Fri, 17 Nov 2023 04:42:43 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9A8FB7; Fri, 17 Nov 2023 01:42:39 -0800 (PST) Received: from IcarusMOD.eternityproject.eu (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id EB9596607394; Fri, 17 Nov 2023 09:42:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1700214158; bh=lCOeXkBHj3GxnYKp57VPx13B7VONqu2PAmr9JmQp0B4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UfywWftonIYwMcfUYDS1omJB0srqfuS56s9ojBC835cHmRmQY/REA9kfrhEuAnmHP AJbqe0hCsLoGngT5ZIB+9sO8ARoh8Ic4z8mgghA29mHFHCz4LjGSvBCdXbhUqifnOl jJtFAWH7mcMEaU43eHd8oRGIsyGHlnA3h7vek8H7nO0GV5avA3Qz6CbhwfcQAPI4SW hf8y6LOAag5gndlwF5M+YE2YYVtnypLWW6NnzqjfkqzHgqEaafAtR7MPKpEUyy1eVx iMmwaIen0pxKpN8y7HOzjD5Ov5YQ9FWyHBk+XJYcfqDEqiCJlTz+eh3GvWJTlyK5s9 ywIUZiUtKK1cQ== From: AngeloGioacchino Del Regno To: matthias.bgg@gmail.com Cc: krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, robh+dt@kernel.org, angelogioacchino.delregno@collabora.com, p.zabel@pengutronix.de, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, kernel@collabora.com, wenst@chromium.org Subject: [PATCH v1 04/20] soc: mediatek: mtk-svs: Build bank name string dynamically Date: Fri, 17 Nov 2023 10:42:12 +0100 Message-ID: <20231117094228.40013-5-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231117094228.40013-1-angelogioacchino.delregno@collabora.com> References: <20231117094228.40013-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In svs_bank_resource_setup() there is a "big" switch assigning different names depending on sw_id and type and this will surely grow: for example MT8186 has got a two-line type (high/low) SVS bank for CPU_BIG, and this would require more switch nesting. Simplify all of this by changing that to a devm_kasprintf() call that will concatenate the SW_ID string (e.g. SVSB_CPU_LITTLE) with the Type string (e.g. _LOW), resulting in the expected full bank name (e.g. SVSB_CPU_LITTLE_LOW). This being a dynamic allocation can be slower, but this happens only once in the life of this driver and it's not a performance path, so it's totally acceptable. Signed-off-by: AngeloGioacchino Del Regno --- drivers/soc/mediatek/mtk-svs.c | 39 +++++++++++++++------------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/drivers/soc/mediatek/mtk-svs.c b/drivers/soc/mediatek/mtk-svs.c index ddbb9ba3e47d..1c7592fd6ae7 100644 --- a/drivers/soc/mediatek/mtk-svs.c +++ b/drivers/soc/mediatek/mtk-svs.c @@ -332,6 +332,14 @@ static const u32 svs_regs_v2[] =3D { [THSLPEVEB] =3D 0x330, }; =20 +static const char * const svs_swid_names[SVSB_SWID_MAX] =3D { + "SVSB_CPU_LITTLE", "SVSB_CPU_BIG", "SVSB_CCI", "SVSB_GPU" +}; + +static const char * const svs_type_names[SVSB_TYPE_MAX] =3D { + "", "_LOW", "_HIGH" +}; + /** * struct svs_platform - svs platform control * @base: svs platform register base @@ -1696,34 +1704,21 @@ static int svs_bank_resource_setup(struct svs_platf= orm *svsp) for (idx =3D 0; idx < svsp->bank_max; idx++) { svsb =3D &svsp->banks[idx]; =20 - switch (svsb->sw_id) { - case SVSB_SWID_CPU_LITTLE: - svsb->name =3D "SVSB_CPU_LITTLE"; - break; - case SVSB_SWID_CPU_BIG: - svsb->name =3D "SVSB_CPU_BIG"; - break; - case SVSB_SWID_CCI: - svsb->name =3D "SVSB_CCI"; - break; - case SVSB_SWID_GPU: - if (svsb->type =3D=3D SVSB_TYPE_HIGH) - svsb->name =3D "SVSB_GPU_HIGH"; - else if (svsb->type =3D=3D SVSB_TYPE_LOW) - svsb->name =3D "SVSB_GPU_LOW"; - else - svsb->name =3D "SVSB_GPU"; - break; - default: - dev_err(svsb->dev, "unknown sw_id: %u\n", svsb->sw_id); + if (svsb->sw_id >=3D SVSB_SWID_MAX || svsb->type >=3D SVSB_TYPE_MAX) { + dev_err(svsb->dev, "unknown bank sw_id or type\n"); return -EINVAL; } =20 - svsb->dev =3D devm_kzalloc(svsp->dev, sizeof(*svsb->dev), - GFP_KERNEL); + svsb->dev =3D devm_kzalloc(svsp->dev, sizeof(*svsb->dev), GFP_KERNEL); if (!svsb->dev) return -ENOMEM; =20 + svsb->name =3D devm_kasprintf(svsp->dev, GFP_KERNEL, "%s%s", + svs_swid_names[svsb->sw_id], + svs_type_names[svsb->type]); + if (!svsb->name) + return -ENOMEM; + ret =3D dev_set_name(svsb->dev, "%s", svsb->name); if (ret) return ret; --=20 2.42.0