From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 4ACE6388890 for ; Tue, 4 Aug 2026 12:00:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844826; cv=none; b=GMXMEqfAYRb4xk43xlixNGgDxYKWvXbd9zgO42ds0k2rtBMgPomjRuavByhe8HPQCNVNSv9Vu8KsaopuUkMBb3szSIbQj2VKEN6p/pb+NRh/cwx/w0exicq3g4ees+Rb7Y1U3ahSkK/s2NMhkE4QmFcXrJspnh6LTxJKQCmgNUI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785844826; c=relaxed/simple; bh=Y1IZ3brM08v8p2grI16N93TT6dsj1XYGzO1ReHQpQ7Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W9UKWfx3mKl/Qwi5CW4ksI5G7LtS9+LAvoEZ3XpzTjEh/HqF3NCY55KKX4Lq6UAVSnY4bwu6taQ/l1xAUfpIsIoK7asO+0td748tSL6Sxe9BgUsaBKvFjBjtZLh7lyHOPMEA5cGubCP3I1eBRlgF1o7R5L3Bx8d99DEhRJxfnec= 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=Gv5zBkMt; arc=none smtp.client-ip=209.85.128.53 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="Gv5zBkMt" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-495590dde14so31485945e9.0 for ; Tue, 04 Aug 2026 05:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785844822; x=1786449622; 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=Y1IZ3brM08v8p2grI16N93TT6dsj1XYGzO1ReHQpQ7Y=; b=Gv5zBkMtWsJ+Ox/3Q1ahdPkZ/HfY1+8GG04v/zs3yXO5Jvjhrn35cxKRMXilsgY1DK +c8JiqzfRHkewyQZqOBcwfbuRTdXLLffqRlS85Hem5QjQmWUnar0VjYwOZhKBpyU6GDf vyPuiEGAlirsDT9rsPrZkjn+Aqf+L0PvgBOYwDEMjsYw4uJJ/ErdtlTnA7VbCSTXYfOF vc8ls+xD8FO+FBA0ULQ24wOHICZh0NH3PF/cH+8P48Wvj4jxy9rFGFmTBU9MMyRuHOg4 q0cHAlaKjR0fMsi+jQh27Vla2i0ucbfbj/NJG4tBGZEasQox0ItSNuIqt/4nAoNznFng KN2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785844822; x=1786449622; 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=Y1IZ3brM08v8p2grI16N93TT6dsj1XYGzO1ReHQpQ7Y=; b=n+qHt8cDEWZw79qOJzbXXBwogWlUyIexVCVSUIOrHuIgYG/Gd15KzJVeGYJ8rhE0/A HKQztdJSyqneEiXgkqhdhd3hq2E+2qh8UCIdMZOtmnYOaeq0ZWm2d3VuITfnTcCo1j7j PUBucXO/maweALKIos/jv/wiu5a4HWbPobD6V6dpsZSOagedMNAKwoYezFpr/w3r/0bg ZFur9R8rzUSd9YQTWPbVZekZOzDGoYrTKuH4KCZwIwBMLyhy3BEOcTfILVcxqznu/8vm JCPTYNxx5j+npOR15qCi2LGi0bqoDZ7406YHLcuEDBRNLA/uoa6J1UGtjAweo+2Zp2o0 5e7g== X-Forwarded-Encrypted: i=1; AHgh+RqwCVNKjby9NL2exN7TpjDTZJ/JuZNKkNyH9FzfNJ6OR5QKgSwRiD/gbtW1w6PTjbCIYpqoZ/P2cvL4OTo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw949bLwA0ifJNO3QyJWo9z+daOPIlXTBR4qODXNlBzx9PjyR/e pivw3zH1uFH8O7zNzY3U65LiqunvNayLjAi26zp28c5xKVmObchrX4Sm X-Gm-Gg: AR+sD12nxvcFPOTl6va6bLTMUlVY7sYhf+0Fece+5QQROmRcoAW1L7smX86jcqu9m43 Hw9eJncZiN5Ya/g3CGbF0JwJRRuS4weYarRC6jsyfysXOr8WHlli2/2UQNcGfxYKbcJCH4iSmP+ IGDG7YbeCoMcwnf4oRzfdzSTL58Zwp4uYU/YI2h+TFOZ4oXnwheUTQ7cIDd9q8nIk6WBPayBgPT KdeRpm1HtglPHeUEOrcZZvTuCmXqNaDImHNhU8dlL5yJ367vcUTk0fLRa/agL4y6uk9+rQLj34v 1OVxaBTHl4SgFxLJlkAP4qYJzJWJEQqdrBsI4JJiVMyxiaoAH51FkZidIKivKBMQczfMMl17ap5 jjkt7gX3FVh67Zaxc8XqB0YDtTsvZ5byaMr5fUAk1w/YOegQDKh1g0XoWe5TymBAjJGLW8/0Jzg FXbYf0XqjY45xcRQour6lH5aWQpIdUb0NIUbTaOH1vhetEx0LlPzaCr01212iwwloR8B5LBy0SW /iv748HrsfYnK2wMY0J/ljLGMA50vY9O91cyIw= X-Received: by 2002:a05:600c:3226:b0:495:3f99:849c with SMTP id 5b1f17b1804b1-4980c6753a3mr190119675e9.15.1785844822328; Tue, 04 Aug 2026 05:00:22 -0700 (PDT) Received: from VivoBook-ASUS-X712UA-M712UA.lan (public-gprs192228.centertel.pl. [46.134.90.37]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49949fe2f4fsm96081735e9.10.2026.08.04.05.00.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 05:00:21 -0700 (PDT) From: Stanislaw Pal To: Jie Luo Cc: Bjorn Andersson , Stephen Boyd , Michael Turquette , Mieczyslaw Nalewaj , Brian Masney , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled Date: Tue, 4 Aug 2026 13:58:17 +0200 Message-ID: <20260804115817.16886-1-kuncy7@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <8af46926-fecc-4396-973e-2290ae285998@oss.qualcomm.com> References: <8af46926-fecc-4396-973e-2290ae285998@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On 8/4/2026 Jie Luo wrote: > The CMN PLL output clocks do not depend on the AHB or SYS clocks. They > continue to operate correctly at the fixed rates even when the AHB > and SYS clocks are disabled. Therefore, once the CMN PLL module is > loaded, its output clocks are expected to operate at the correct > frequencies. > > The downstream consumer is used to keep the AHB and SYS clocks enabled, > allowing the CMN PLL registers to be accessed. Agreed on both points, and they match what I measured: with the bus clocks gated the PLL outputs keep running (ethernet and wifi stay clocked), only register access dies. But I think these two points together are exactly the argument for the patch. The register accesses do not stop when there is no consumer: the CCF invokes the driver's ops regardless. clk_cmn_pll_recalc_rate() does two regmap_read()s and runs on any clk_get_rate() of the PLL and on every debugfs clk_summary read - the latter user-triggerable at an arbitrary time. clk_cmn_pll_set_rate() likewise accesses registers whenever a rate is set. On IPQ5018, where no DT consumer exists at all, every one of those calls after probe touches the block with AHB/SYS gated, and that is the measured hang - the boards died during boot with no userspace involved, so an in-kernel path hits it too. And note the consumer mechanism only guarantees access "while the consumer is active": on the SoCs that do have a DT consumer, a runtime-suspended consumer plus a clk_summary read is the same access-with-gated-clocks situation, just harder to hit. So having the provider hold the reference for as long as it can be asked to service clk ops - i.e. while bound - seems like the robust shape regardless of platform. I have just posted v2 which does exactly that, in a cleaner form: devm_pm_runtime_get_noresume() in probe, so the reference is dropped automatically on unbind and the existing put in the error path stays untouched. Thanks, Stanislaw