From patchwork Fri Sep 9 12:31:10 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 12971705 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E61B9ECAAD3 for ; Fri, 9 Sep 2022 12:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Sb5pJSXh9FJixwAkjqAAxz2hjfnuA/1U1KMYI9dcrpo=; b=b4C1AY0G2f+9Rk D/NJcJR40m2c5uJSVH1FfBWzTknfB5jzHCHt/Y1fhEm4PymqRpFcUlQ/atDzG+Iut3h1DVtEkiFX0 9k/SHeUxQeeKgOdngUsl80GH03E6FznR7R0xOihCv00lge2QFejimZPBozpD3LcCnqD763T82noxK nRYjMGquHBQSVT+lTMRU115PmWM0Z+dj4gRXztyHp5cB5iDgFkKeK4/U9tlcmKd/dP8mrqRgrCxqb 389/X2+d4U/p/Hm/HBJDa9o6e+/jRd+95VNYZPt6vRNtVNffb/S+UwtprMdhPv6/YzFFWOtiVYlji RSRjypOd6pFDZIbxBjiw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWdB0-00G28h-RU; Fri, 09 Sep 2022 12:32:06 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oWdAw-00G25X-Qh for linux-riscv@lists.infradead.org; Fri, 09 Sep 2022 12:32:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1662726722; x=1694262722; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J/KA5IP1P64+fZAZNeRF2iSfGho/kaCFDpeCMd5oTCw=; b=zt1DUWJI2ymxh6PXCjthkQU73eisX2G4opAfX4t4YzR/FncgCUaTfjk6 BKsSi3+xJe26WKxsfozz4yx2EThATwz6rKWFrXqNx4bb1x5tAP0to0yWJ ofZNBlZ5O9DDFHBVWgjvD1tt/aZJifVBBULc1wYiAVP1EyyNnDL5E5gb5 6tKrxpJNVOBIH6oyX/ianZTfLOndqSJnnFolvjtXiN7w4qU7/wP1FT2j5 bHr7FmP7MJntDBE1V1DdxFtokawb9VfTU3kFAiLC+ug6cJrWmE+S4lAUK FbWnLbQfY1BMata9wDC0B5XYDTZ50aKMJotHF7aTO/ltiYj9Rl2lVQdxh g==; X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="176399082" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa2.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 09 Sep 2022 05:31:51 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Fri, 9 Sep 2022 05:31:49 -0700 Received: from wendy.microchip.com (10.10.115.15) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server id 15.1.2507.12 via Frontend Transport; Fri, 9 Sep 2022 05:31:46 -0700 From: Conor Dooley To: Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Palmer Dabbelt , Conor Dooley , Daire McNamara CC: Paul Walmsley , Albert Ou , Claudiu Beznea , , , , , "Nathan Chancellor" Subject: [PATCH v5 01/14] clk: microchip: mpfs: fix clk_cfg array bounds violation Date: Fri, 9 Sep 2022 13:31:10 +0100 Message-ID: <20220909123123.2699583-2-conor.dooley@microchip.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220909123123.2699583-1-conor.dooley@microchip.com> References: <20220909123123.2699583-1-conor.dooley@microchip.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220909_053202_949293_E4B61F09 X-CRM114-Status: GOOD ( 14.58 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org There is an array bounds violation present during clock registration, triggered by current code by only specific toolchains. This seems to fail gracefully in v6.0-rc1, using a toolchain build from the riscv- gnu-toolchain repo and with clang-15, and life carries on. While converting the driver to use standard clock structs/ops, kernel panics were seen during boot when built with clang-15: [ 0.581754] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b1 [ 0.591520] Oops [#1] [ 0.594045] Modules linked in: [ 0.597435] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-00011-g8e1459cf4eca #1 [ 0.606188] Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) [ 0.613012] epc : __clk_register+0x4a6/0x85c [ 0.617759] ra : __clk_register+0x49e/0x85c [ 0.622489] epc : ffffffff803faf7c ra : ffffffff803faf74 sp : ffffffc80400b720 [ 0.630466] gp : ffffffff810e93f8 tp : ffffffe77fe60000 t0 : ffffffe77ffb3800 [ 0.638443] t1 : 000000000000000a t2 : ffffffffffffffff s0 : ffffffc80400b7c0 [ 0.646420] s1 : 0000000000000001 a0 : 0000000000000001 a1 : 0000000000000000 [ 0.654396] a2 : 0000000000000001 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.662373] a5 : ffffffff803a5810 a6 : 0000000200000022 a7 : 0000000000000006 [ 0.670350] s2 : ffffffff81099d48 s3 : ffffffff80d6e28e s4 : 0000000000000028 [ 0.678327] s5 : ffffffff810ed3c8 s6 : ffffffff810ed3d0 s7 : ffffffe77ffbc100 [ 0.686304] s8 : ffffffe77ffb1540 s9 : ffffffe77ffb1540 s10: 0000000000000008 [ 0.694281] s11: 0000000000000000 t3 : 00000000000000c6 t4 : 0000000000000007 [ 0.702258] t5 : ffffffff810c78c0 t6 : ffffffe77ff88cd0 [ 0.708125] status: 0000000200000120 badaddr: 00000000000000b1 cause: 000000000000000d [ 0.716869] [] devm_clk_hw_register+0x62/0xaa [ 0.723420] [] mpfs_clk_probe+0x1e0/0x244 In v6.0-rc1 and later, this issue is visible without the follow on patches doing the conversion using toolchains provided by our Yocto meta layer too. It fails on "clk_periph_timer" - which uses a different parent, that it tries to find using the macro: \#define PARENT_CLK(PARENT) (&mpfs_cfg_clks[CLK_##PARENT].cfg.hw) If parent is RTCREF, so the macro becomes: &mpfs_cfg_clks[33].cfg.hw which is well beyond the end of the array. Amazingly, builds with GCC 11.1 see no problem here, booting correctly and hooking the parent up etc. Builds with clang-15 do not, with the above panic. Change the macro to use specific offsets depending on the parent rather than the dt-binding's clock IDs. Fixes: 1c6a7ea32b8c ("clk: microchip: mpfs: add RTCREF clock control") CC: Nathan Chancellor Signed-off-by: Conor Dooley Reviewed-by: Claudiu Beznea --- drivers/clk/microchip/clk-mpfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/microchip/clk-mpfs.c b/drivers/clk/microchip/clk-mpfs.c index 070c3b896559..f0f9c9a1cc48 100644 --- a/drivers/clk/microchip/clk-mpfs.c +++ b/drivers/clk/microchip/clk-mpfs.c @@ -239,6 +239,11 @@ static const struct clk_ops mpfs_clk_cfg_ops = { .hw.init = CLK_HW_INIT(_name, _parent, &mpfs_clk_cfg_ops, 0), \ } +#define CLK_CPU_OFFSET 0u +#define CLK_AXI_OFFSET 1u +#define CLK_AHB_OFFSET 2u +#define CLK_RTCREF_OFFSET 3u + static struct mpfs_cfg_hw_clock mpfs_cfg_clks[] = { CLK_CFG(CLK_CPU, "clk_cpu", "clk_msspll", 0, 2, mpfs_div_cpu_axi_table, 0, REG_CLOCK_CONFIG_CR), @@ -362,7 +367,7 @@ static const struct clk_ops mpfs_periph_clk_ops = { _flags), \ } -#define PARENT_CLK(PARENT) (&mpfs_cfg_clks[CLK_##PARENT].hw) +#define PARENT_CLK(PARENT) (&mpfs_cfg_clks[CLK_##PARENT##_OFFSET].hw) /* * Critical clocks: