From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91917288C2D for ; Fri, 4 Sep 2026 13:09:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788527367; cv=none; b=XiCHfzzNTT1aWL7ltRdlJkMcoZpBMKcFo8WGbj5hkeepI2IAw9y8tvkiKafsyos3zJ8ZtOdujkFzaHTClFyOq10Xg4+jvI8cAeVgOSEsNWz1siJZZchtPwAwenc3h+O3q8GRHvP4yL6Id+SxBpJ0NtLzd6mqecJ+YM/SJf4UQWY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788527367; c=relaxed/simple; bh=DXP7b9aeuGMlpb6EbUoiOrTeOWhkU0hKUHsr29rOjmk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HZ9R9JAnD2Pz/swit+YZUn33O9KhH5JA444GKZzBkHJtJg+e0lsf/AOuRPcd5flygTHOrUqAtIeDqd5BsfLTFdHOOljytu0i0MeAteubWTVCyNa6MRKRKXpeFlxQKL/cL0igGeNDbNbBIu0vzKT4QMk9LSWh7ggLssnvYQHA3ZI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hqXlPFuS; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hqXlPFuS" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4956d1d9fb2so929645e9.0 for ; Fri, 04 Sep 2026 06:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788527364; x=1789132164; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=t7o7pGTYJ1j9htjyKompyXPu5oGlEszk3L/eQl+FLhg=; b=hqXlPFuS6+NM7baHIqPdcb0pkKcP+P2FnxBeR0g0W6w+WA/iLZLKzDj+azJxR9j8Gs /W/eAjmGoAqL8loW5TAdoaEX2r0cOUHJhqSTAd6Adc1bQY9ymlFUOSg6uQGBJ7UDkWYp Y9B3R82NM9mG+M9OIuYUEmOjrZKcbf5TyvNEcCBm844eiOor0zw7r3SFfXIdSudANmrW j5h0LOrL/YHtWXhUom/MxRPAavMv2DENc295FOXn1aU06C6vkSIY08/jOPDBUZI/iS+p PrhXuoumdmp5aZw2ZC9WF/4wCDXXAO/UPtO7VW9/7rWFxuEa96jkGlr8EzXfqupet/kM YPvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788527364; x=1789132164; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=t7o7pGTYJ1j9htjyKompyXPu5oGlEszk3L/eQl+FLhg=; b=iYgehoHW/+n3XwkNH7CSVj0ht/8w97KJr9grgLQ/6CwNotRF7076T4cYJCh9E3TVxP S86tMrGeYDDNRFaUSmRU5oYkw8tnbBKSLi9pyxWDAZILBctAxRJKezwxMJTOS4MGNbtw PAy77VHQ1VGYo/3Z/bAFWHpR4V7az0RxoOmxKj4eI0VUVDLlgQCcA3u8oRhWrisX1+Y4 dLH+rw2NLvHwY47kdXgEfUGOcw1IZsb00JSxW0QuQTjHXbu2loxpyaIQWWrD+dkdDOE9 mMRmP43oWKnH+TrKs1ImVzmM1C0c4AJ5lE58CxZkMYWsfRkMQ5c6pAD4LvvFBjHMSafl 0hXQ== X-Forwarded-Encrypted: i=1; AKwUvBwYCRlAjUT4ldco0E28P2RMNKe39Pv/TQ1GlR47YZQGK8Ew2NJ9ajM0YlorhNX1m9TAG0aZwFVVAi0r@vger.kernel.org X-Gm-Message-State: AFuF++lO+pb0WrrxJL6LPpIQsR7zncwZqhzaB5iPCk9r2AO0g7pjaImU Xs1wow54YCLxdVTPVjoTaKWs4N9EbpXu85OAH7AJv4DWYHTT2E2/x3P5 X-Gm-Gg: AYBFou3bgTLv8vj09srP9bMugVfG1gNU6FOP6tVLwoOVwOlcJEvP7DzKyTQyW0/nFA3 uucums5FnMIsUGfbw4xIIvGYUErUkv/aXlKT8m9KOTp6YeTKqySDTthi/DyMZyH78BTbCoROzTF xqMPBJXncrGvk8txamV1Qn3ZR7uPoIS5PWen9WR6Lp36ufqnSqghua2odvaZ3ZRI/B3xutfA9zE n5c/nFFYNbn4BFO5a9ipTbHIL3IXzsIxSw1rhDjbYwwJa5w7z72YPmiG2reVryK1V6wPpl1IMgc Mx/YAHsRYIgjFbsVLgqh8//mlT2B49cTjZvJiQbZL1/DfQOLvi3ErUp1MqAhxKskRP1mi1J9jkY VThU4zk2EXmgt9NmjzTOoWay71trVRPGO1aoZEpiwTw0p3v5yJ3cO6z6uotIJbBYQSXTtBPuFf0 UYVbZhwi/udMEf7sELxk3WJHrE5TWnh8NYpnHiDzDreFysMljNQDaGADMGQrVp+oVLGrN4Bq+qD OngM+x9JM1ZByTlDCItuHkueD8P3wYUE2O23buF1vTcQwHOU4NVnolLz0SRQG2GQpg7jJMgqs1L PCc= X-Received: by 2002:a05:600c:8b6d:b0:49c:e363:c66e with SMTP id 5b1f17b1804b1-49cf82420afmr41030795e9.1.1788527363631; Fri, 04 Sep 2026 06:09:23 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B871500CB6EF488A18F9C42.dsl.pool.telekom.hu. [2001:4c4e:1b87:1500:cb6e:f488:a18f:9c42]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce554d52esm135575435e9.3.2026.09.04.06.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 06:09:23 -0700 (PDT) From: Igor Paunovic To: Tomeu Vizoso , Oded Gabbay , Heiko Stuebner Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sidong Yang , Diederik de Haas , Sebastian Reichel , Jiaxing Hu , Nicolas Dufresne , Jonas Karlman , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Igor Paunovic Subject: [PATCH 1/7] accel/rocket: request the core clocks by name Date: Fri, 4 Sep 2026 15:08:52 +0200 Message-ID: <20260904130858.27803-2-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904130858.27803-1-royalnet026@gmail.com> References: <20260904130858.27803-1-royalnet026@gmail.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit rocket_core_init() hands core->clks to devm_clk_bulk_get() without ever setting the .id members. The rocket_core array is allocated with devm_kcalloc() in rocket_device_init(), and rocket_probe() only fills in .rdev, .dev and .index, so all four clk_bulk_data entries are requested with a NULL con_id (unlike core->resets, whose ids are set a few lines above). clk_get(dev, NULL) ends up in of_clk_get_hw(np, 0, NULL), and of_parse_clkspec() only consults "clock-names" when a name was passed, so the index stays 0 for all four entries. Every entry therefore ends up holding a handle to the *first* clock of the DT "clocks" property, i.e. ACLK_NPUn. Nothing fails: probe succeeds and the driver believes it owns four different clocks. The consequence is that rocket_device_runtime_resume() prepares and enables the AXI clock four times, while hclk, pclk and - most importantly - the NPU compute clock ("npu", SCMI_CLK_NPU on RK3588) are never prepared or enabled by this driver at all. The NPU still works only because the Rockchip power-domain driver sets GENPD_FLAG_PM_CLK and its attach_dev() callback walks the device node with of_clk_get() and adds every clock to the pm_clk list, so genpd happens to keep the remaining clocks running. The bug is therefore latent today, but it means the driver holds no reference to the clock that actually feeds the NPU, which stands in the way of any future frequency scaling (OPP/devfreq) work. Found on an Orange Pi 5 Plus (RK3588) by reading the live clock tree: /sys/kernel/debug/clk/clk_summary shows four "fdab0000.npu" consumer handles on aclk_npu0 (and likewise on aclk_npu1/aclk_npu2 for the other two cores), while hclk_npu0, pclk_npu_root and scmi_clk_npu have no "fdab0000.npu" consumer at all - their only consumers are the "npu@fdab0000" handles created by the power-domain driver via of_clk_get(). Set the ids explicitly, in the order mandated by the binding (Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml): aclk, hclk, npu, pclk. After the change the driver holds one handle per distinct clock and clk_bulk_prepare_enable() covers all four. Note that this is a user-visible tightening for out-of-tree DTs: the old NULL-id requests resolved by index and succeeded no matter what "clock-names" contained, while the named requests fail probe with -ENOENT when one of the four names is missing. That is the right outcome for in-tree users - the binding requires exactly these four clock-names and rk3588-base.dtsi carries them on all three cores - but a DT that relied on the permissive lookup goes from silently running on the wrong clock handles to not probing at all, so record the change here where git log will find it. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Signed-off-by: Igor Paunovic Tested-by: Sidong Yang Tested-by: Diederik de Haas # NanoPC-T6 LTS, NanoPC-T6 Plus Reviewed-by: Sebastian Reichel Reviewed-by: Jiaxing Hu Signed-off-by: Jiaxing Hu --- drivers/accel/rocket/rocket_core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rocket_core.c index b3b2fa9ba645a..5dd260bacbff6 100644 --- a/drivers/accel/rocket/rocket_core.c +++ b/drivers/accel/rocket/rocket_core.c @@ -28,6 +28,10 @@ int rocket_core_init(struct rocket_core *core) if (err) return dev_err_probe(dev, err, "failed to get resets for core %d\n", core->index); + core->clks[0].id = "aclk"; + core->clks[1].id = "hclk"; + core->clks[2].id = "npu"; + core->clks[3].id = "pclk"; err = devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks); if (err) return dev_err_probe(dev, err, "failed to get clocks for core %d\n", core->index); -- 2.43.0 From mboxrd@z Thu Jan 1 00:00:00 1970 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 E1993C79F82 for ; Fri, 4 Sep 2026 13:09:32 +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=Sma9udRGXj7Y0TiofQ8ov7e+hqLBzheGiqGvrZP/xwU=; b=Tb1vCtLCwrDY+g RYkVhZnpJlOoXwYHLZtIhy3282vn40NAdmJjDn32qgfi+rvAkip3EA9Qt7XLYOTeul5oNXO4PqPKJ GCK2beckvOXK7n5blViveAF6ekp/zUPjUUYY3r/MCwnDjfFJmiPt0wyOToVylhxmWiyhW7+ZJNWl3 DXMp1aai+HlAmINrDOfrPz1bsfLehdtEd/5ZGH4o1Ef33wkWEvr37byx8ntuTUfy3wjaam0mNzSk1 IKNYKZ1F41p9XMrV4As0mBppDqzIXAv2yug+3XrWdAbeuwI/wlYGstOHieQibxVn+7432DtFn3Phz TFxgzQalmxTXTZ2TSqiA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x2Tfe-000000026bb-2QeA; Fri, 04 Sep 2026 13:09:30 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x2TfZ-000000026Wc-2T2l for linux-rockchip@lists.infradead.org; Fri, 04 Sep 2026 13:09:27 +0000 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4956d1d9fb2so929635e9.0 for ; Fri, 04 Sep 2026 06:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788527364; x=1789132164; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=t7o7pGTYJ1j9htjyKompyXPu5oGlEszk3L/eQl+FLhg=; b=ipKz573IdnlcGH7T1lpimyKXwVeGbmhth5tgaN/1/8wXbs9x0cGnbG/T6RSMn6tu+o AJqpnGOy8f/d/TwwBcn3A67crw5TEGNZbKuxkUyMYhkZvP68vpUMHbxrOuQoZAhgzAtP mxnsWUp/3jByBXOhDXP30qVdhr5ZmHZFPwtZfuq489WikvF/Xze6Q61+NilkZrRnsg0t UqXk9WPOazPeJAnBib2E3GHMazE6LXZjlHJqS4+IsBGpP0IUekBECo40TVeLT8HKvixt oCgOAV5IXm70yZAgQ+cgIv9KIXLsc8xhOxsAtQPHTTbcW6MSZcugCldQPpJQiq+Dsp4d M6NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788527364; x=1789132164; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=t7o7pGTYJ1j9htjyKompyXPu5oGlEszk3L/eQl+FLhg=; b=LeS3F++mGrCXZm3/PSesGCB+EVnWZPx7LRgCNCrqchsWD/mJ4vpiNOBcLWSB3pJsiP DWK5inEtk+09923elvaTd6MhKN7S++o90ucLjk9SOq+nIhkdzpUvLUzGX3FBPdZGYEyp fUqyp0xJFqbriNuvdE/NolPQMcYvrm3pPymKAW7WbqWilcqtTWmc15+j8wvLH3YYuHzQ zDSk/L+q24Bm1B9KV1dXpu+HqscUP0rAeNLYjnkUQKx061VQ7u5NJhQRGWFiM2/kUxZr 3T4CHPLvroKE78W202ohiAqAEwxz5HEpFDm4BoikOO0m+Dch0QD/g07qhbTK1xuC+Em5 FmfA== X-Forwarded-Encrypted: i=1; AKwUvBxg2hCNnTFWQWfhoWK+9ToGym+Vmhb6DXo7/bjGIZqCSYM3oNwaAGyu4aHBEITD4jetThZsXxE2YFzqdgzcIQ==@lists.infradead.org X-Gm-Message-State: AFuF++keWFd/B05UX/u/RcltBohxQMmXwpIdpkvOYP2pDpCNqTyXT8LP Hg3TQsUvK8UYZGM9Lf9MTXY7rx6JFcWjBKYj7yz6k7FE/KQkLlwlqbUK X-Gm-Gg: AYBFou1LpEu3nleSUcHNPdT3bnoN9XNAAZNhxP7jgW7O0RWzAfS2SzrekmQEXxPlIxZ rNv1yUXl6HBFNpLIgfZe9kxAdyECvoOVMNicQ0W7tFGFLAK5wg9av8V6Fo1+DzXcaltz5dN3uvV UVxmDUK45rt4BRZcVkxO85eKWABSKuZPQEVqzf29wJw5O0GLm1it5DOiMZp9I0icmAxFcQsB/RK q6URcTHokN2xGLdE5GGZ0LqeF8rZSYpZolZ+e2LvwGIfNiRP9/468UIm5TOdfdkW4QYEhUuy8SN xs3mTUtbplhMbLJT6sufkUlJLxDVdMfHLz5m0/V79uFmJM3NpKYfsfC3Rm+pEyL4P8sV/msgILU XYxV0SvGDTpClXTxT+DTcjy5pjEupLxH6pBvPqKW+3X57nkbhOErwbTk2cCRIoCwF2X7BcS+t+Y TQZVAVsVpu2WnC7ji1NAMpY7RnDIiKWjkoo+54cQCqFRBxfUlJhhGYQAVYy3pJhHNiUw2NGKk2O NmhDSV/2AXOGwlrwkYmqWp+2NQwF5dTlBkgs0NiWUDXE1MOkTrsZZSN4PpgGQlHhLY9qC3Lzmju KCc= X-Received: by 2002:a05:600c:8b6d:b0:49c:e363:c66e with SMTP id 5b1f17b1804b1-49cf82420afmr41030795e9.1.1788527363631; Fri, 04 Sep 2026 06:09:23 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B871500CB6EF488A18F9C42.dsl.pool.telekom.hu. [2001:4c4e:1b87:1500:cb6e:f488:a18f:9c42]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49ce554d52esm135575435e9.3.2026.09.04.06.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Sep 2026 06:09:23 -0700 (PDT) From: Igor Paunovic To: Tomeu Vizoso , Oded Gabbay , Heiko Stuebner Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sidong Yang , Diederik de Haas , Sebastian Reichel , Jiaxing Hu , Nicolas Dufresne , Jonas Karlman , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Igor Paunovic Subject: [PATCH 1/7] accel/rocket: request the core clocks by name Date: Fri, 4 Sep 2026 15:08:52 +0200 Message-ID: <20260904130858.27803-2-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260904130858.27803-1-royalnet026@gmail.com> References: <20260904130858.27803-1-royalnet026@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260904_060925_647595_13010EC1 X-CRM114-Status: GOOD ( 18.12 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org rocket_core_init() hands core->clks to devm_clk_bulk_get() without ever setting the .id members. The rocket_core array is allocated with devm_kcalloc() in rocket_device_init(), and rocket_probe() only fills in .rdev, .dev and .index, so all four clk_bulk_data entries are requested with a NULL con_id (unlike core->resets, whose ids are set a few lines above). clk_get(dev, NULL) ends up in of_clk_get_hw(np, 0, NULL), and of_parse_clkspec() only consults "clock-names" when a name was passed, so the index stays 0 for all four entries. Every entry therefore ends up holding a handle to the *first* clock of the DT "clocks" property, i.e. ACLK_NPUn. Nothing fails: probe succeeds and the driver believes it owns four different clocks. The consequence is that rocket_device_runtime_resume() prepares and enables the AXI clock four times, while hclk, pclk and - most importantly - the NPU compute clock ("npu", SCMI_CLK_NPU on RK3588) are never prepared or enabled by this driver at all. The NPU still works only because the Rockchip power-domain driver sets GENPD_FLAG_PM_CLK and its attach_dev() callback walks the device node with of_clk_get() and adds every clock to the pm_clk list, so genpd happens to keep the remaining clocks running. The bug is therefore latent today, but it means the driver holds no reference to the clock that actually feeds the NPU, which stands in the way of any future frequency scaling (OPP/devfreq) work. Found on an Orange Pi 5 Plus (RK3588) by reading the live clock tree: /sys/kernel/debug/clk/clk_summary shows four "fdab0000.npu" consumer handles on aclk_npu0 (and likewise on aclk_npu1/aclk_npu2 for the other two cores), while hclk_npu0, pclk_npu_root and scmi_clk_npu have no "fdab0000.npu" consumer at all - their only consumers are the "npu@fdab0000" handles created by the power-domain driver via of_clk_get(). Set the ids explicitly, in the order mandated by the binding (Documentation/devicetree/bindings/npu/rockchip,rk3588-rknn-core.yaml): aclk, hclk, npu, pclk. After the change the driver holds one handle per distinct clock and clk_bulk_prepare_enable() covers all four. Note that this is a user-visible tightening for out-of-tree DTs: the old NULL-id requests resolved by index and succeeded no matter what "clock-names" contained, while the named requests fail probe with -ENOENT when one of the four names is missing. That is the right outcome for in-tree users - the binding requires exactly these four clock-names and rk3588-base.dtsi carries them on all three cores - but a DT that relied on the permissive lookup goes from silently running on the wrong clock handles to not probing at all, so record the change here where git log will find it. Fixes: ed98261b4168 ("accel/rocket: Add a new driver for Rockchip's NPU") Signed-off-by: Igor Paunovic Tested-by: Sidong Yang Tested-by: Diederik de Haas # NanoPC-T6 LTS, NanoPC-T6 Plus Reviewed-by: Sebastian Reichel Reviewed-by: Jiaxing Hu Signed-off-by: Jiaxing Hu --- drivers/accel/rocket/rocket_core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/accel/rocket/rocket_core.c b/drivers/accel/rocket/rocket_core.c index b3b2fa9ba645a..5dd260bacbff6 100644 --- a/drivers/accel/rocket/rocket_core.c +++ b/drivers/accel/rocket/rocket_core.c @@ -28,6 +28,10 @@ int rocket_core_init(struct rocket_core *core) if (err) return dev_err_probe(dev, err, "failed to get resets for core %d\n", core->index); + core->clks[0].id = "aclk"; + core->clks[1].id = "hclk"; + core->clks[2].id = "npu"; + core->clks[3].id = "pclk"; err = devm_clk_bulk_get(dev, ARRAY_SIZE(core->clks), core->clks); if (err) return dev_err_probe(dev, err, "failed to get clocks for core %d\n", core->index); -- 2.43.0 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip