From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 BA3F13AAF64 for ; Thu, 30 Jul 2026 19:13:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785438840; cv=none; b=XgPLM9Xd8uGEv2RoGR87NobekPKXqqVrDBqGBq29TqMDC6XGg1ifHxGQSG/mFv82GPy/k4Uwe9SKhs/AE7OAnXKtuQ0pH/34BSQxOqlbF3AIfENcr62LXGJQNHvT2LisQ6rHoDOa4ZyjG/C00EYj6O9RIXlxK7FIOXN080y1FLE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785438840; c=relaxed/simple; bh=Topwf+V3jfuUiuzqOBdaGECWQDvVXswPedPSAJACfQo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JBoJ2BUZtHpSrtVCOZHsvmoHKl5SloYnbrFmZI9I4sBDR4fyqCnA6Dt7Z9CNsCVsALC1ryfqVw9IUqLUySwwx/SoEwhwC3Y68RcgJpQyiJaGJw4DQC57d/cg5C88FmbYPisRCplLbgb3dtCNPLiAMZ91ySjazwTGTWywUkadCJg= 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=mr2ny54t; arc=none smtp.client-ip=209.85.128.41 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="mr2ny54t" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4956869750eso723035e9.2 for ; Thu, 30 Jul 2026 12:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785438837; x=1786043637; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=RD3lmsuBeFnVrxhklpYzLfUZAUon1UxgAvihRoA5NDM=; b=mr2ny54tuo212MTH/DQS6J6QiCZLVFtAdpF2X6zZ2VBd91l0ooyVJiFXoOY4ptYY8H wvdGye81wyLx1Iuxa5q98YbSSo4I1tThXaER564wh9ZSNOZUijD57OqP+cRHVkxB0alq Xts18V0K6C8B+3OtGYvNkQpEzyOnpRaiuofhAf19MllXKSyQkJi1Bt/b5auSULJ4xMzF ACRqORVPhprh1HvL2Rc3Sk1OLI+RjfaY2XL/GiDXWrFte3xNKo/FKKvkw3Z0W0Du7Tei iFyzYHjE4FtiOVeumdnxNxB16921UK8RlYselZZBnSnydBX3IVFD4ECNJ6Kfu+vm0rzh Ukig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785438837; x=1786043637; h=content-transfer-encoding:mime-version: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=RD3lmsuBeFnVrxhklpYzLfUZAUon1UxgAvihRoA5NDM=; b=YxX1YUQ9cBvhA/sy3gYqvpfwQ+incc5U7ZBp+W53HtKenbOFTFbasWKZCV7uV1wFip YZi94SRp/uz5msYqG2bJKZ6aCRNQqR4LCIrh5fOWaTi0i7cGpIfQynlYVC7jJQ+VPUUx wUS6TA0d0MpKcBveeCHYjDSsfUzFQV/ovVE8tOw+J3NlqG4BIHeTJZOKGMn1fywK/SjY 26JArVq2a41itg43rMbfX7q+q1+/+BN/mqCNTmucpH1UzNQfC/4pWCnSFPo7YNYdZQJ1 L3+Js/KATFQW+0SAFQVPwwFZXSHEPZXApydtHypRnvMmp6jp7x7hGOXTB1EwgUpbrN3P asng== X-Forwarded-Encrypted: i=1; AHgh+RoTtmCM+823Ih5NXe1qcWW2BHm79IiW4mTbSUHqZsUMZ+DMI0OgDaKdCNx35L46rphBZ4lWM8AwVP4sItQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwpvIkHpn6TFMCQ5YHwZpYwyrWLL8SufNkq8+N7xbgdZEy9pdL9 jjhK7pdsDvIYgJmGyus7zwwSztCiCQC7+mJPTUkCiyk8oL3Qa/8G5dVF X-Gm-Gg: AR+sD11y6MD/gCs6srT1yd7sAWxb38Lbn0GFI6jXSpOM9N0o6mCINJ/5uS65lIPWXB3 x5XZ34HMZZc7vD0pNPQiuCEvIzWXw2L1LRq2IYTmVPj5FvEERAyq76wvsEsKE+tX59ju8dEgS4j wyrnE0V4U3PAr/WV5kvnuoeiXnX2jqGKq7AWWfWC6289ujN50FscKdivrVMLX4497uHvjGKfJVz Pp93T1S1wcYsfYt0+nuuhfR+GzaLA9A8tqS76aoHjODbiOWYopWm4KFXsjz6tOHgDC9xNz+RVou KNXjaPRNKRQ0qpkgzODf/BFEUx1NdMeuXdRsKtBcfW6w15s66Ohb/RceOVwZybemEtwuwJQdKwS oYSxiERcr0Bl5WKtLFJ000/6VD3LGNLL55Eg7eLjhbzOvIO/OFg0osN3+xzfLCflAOX0v9JReKt AGooZiWNY+BgRxb2eiY8q+ggaDnBomzCgOKJdRROMSOCFOpNcI4i/ezD3uvwio/4AOjkyPy9xsf y1qw4UOBzPQZHLe+MtL4CtJS2uEjnelDiC4w8YwO8oZImZqdhE= X-Received: by 2002:a05:600c:41c1:b0:495:5b02:23b0 with SMTP id 5b1f17b1804b1-49800eabb56mr33840125e9.26.1785438836682; Thu, 30 Jul 2026 12:13:56 -0700 (PDT) Received: from VivoBook-ASUS-X712UA-M712UA.lan (public-gprs192625.centertel.pl. [46.134.91.178]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-498011e5febsm76121635e9.3.2026.07.30.12.13.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 12:13:56 -0700 (PDT) From: Stanislaw Pal To: Bjorn Andersson , Stephen Boyd , Michael Turquette Cc: Luo Jie , Brian Masney , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Stanislaw Pal Subject: [PATCH] clk: qcom: ipq-cmn-pll: keep the CMN block bus clocks enabled Date: Thu, 30 Jul 2026 21:13:53 +0200 Message-ID: <20260730191353.557494-1-kuncy7@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The probe function takes a runtime PM reference to enable the GCC AHB & SYS clocks of the CMN PLL block, registers the clocks, and then drops the reference. Once the autosuspend kicks in, pm_clk gates both clocks a few milliseconds after probe has returned. That is wrong on two counts: - The clock ops access the CMN PLL registers without taking a runtime PM reference of their own, so any later clk_set_rate() or rate recalculation touches the register file with its bus clock gated. - On IPQ5018 the consequences are not contained to this device: gating the CMN block bus clocks makes the SoC hang on a subsequent bus access. Measured on a TP-Link Archer AX55 v1 (IPQ5018), the machine dies silently within a few milliseconds of the CMN PLL probe returning - mid-character on the UART - and the victim is whichever device happens to probe next. Whether a given boot survives the window is a micro-timing lottery: different binary layouts of the same kernel ranged from occasional failures to a 100% reproducible boot loop. Keep the runtime PM usage count elevated on the probe success path, so the bus clocks stay enabled. With this one change the same board went from boot-looping to surviving every boot attempt (verified across three previously-failing kernel binaries, plus repeated soft and hard resets on the final one). Fixes: f81715a4c87c ("clk: qcom: Add CMN PLL clock controller driver for IPQ SoC") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Pal --- One more observation from the same debugging session, for the people who know this silicon: on IPQ5018 the CMN_PLL_LOCKED bit (offset 0x64, bit 8) never asserts. Every clk_cmn_pll_set_rate() call runs its regmap_read_poll_timeout() to the full 100 ms timeout - including under the bootloader-programmed configuration the hardware demonstrably runs fine with - and nobody notices, because clk_change_rate() ignores the .set_rate return value, so the -ETIMEDOUT is swallowed silently. Is the lock status readable at a different offset on this SoC, or is the bit simply not functional there? Happy to send a follow-up (surfacing the error, or skipping the poll where it cannot work) once someone can say what the intended behavior is. drivers/clk/qcom/ipq-cmn-pll.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/clk/qcom/ipq-cmn-pll.c +++ b/drivers/clk/qcom/ipq-cmn-pll.c @@ -454,11 +454,19 @@ /* Register CMN PLL clock and fixed rate output clocks. */ ret = ipq_cmn_pll_register_clks(pdev); - pm_runtime_put(dev); - if (ret) + if (ret) { + pm_runtime_put(dev); return dev_err_probe(dev, ret, "Failed to register CMN PLL clocks\n"); + } + /* + * Keep the runtime PM usage count elevated on the success path, so + * the CMN block AHB & SYS clocks stay enabled: the clock ops access + * the CMN PLL registers without taking a runtime PM reference, and + * on IPQ5018 gating these clocks after probe hangs the SoC on a + * subsequent bus access. + */ return 0; }