linux-kernel - Re: [PATCH 0/2] driver core: platform: / drm/msm: dp: Delay applying clock defaults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DC5KCSEUZQUJ.3KPENNUQBUFM8@kernel.org>
Date: Mon, 18 Aug 2025 14:47:55 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "Stephan Gerhold" <stephan.gerhold@...aro.org>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
 "Danilo Krummrich" <dakr@...nel.org>, "Stephen Boyd" <sboyd@...nel.org>,
 "Michael Turquette" <mturquette@...libre.com>, "Dmitry Baryshkov"
 <lumag@...nel.org>
Cc: "Rob Clark" <robin.clark@....qualcomm.com>, "Abhinav Kumar"
 <abhinav.kumar@...ux.dev>, "Jessica Zhang"
 <jessica.zhang@....qualcomm.com>, "Sean Paul" <sean@...rly.run>, "Marijn
 Suijten" <marijn.suijten@...ainline.org>, "David Airlie"
 <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>, "Rob Herring"
 <robh@...nel.org>, "Conor Dooley" <conor+dt@...nel.org>,
 <linux-kernel@...r.kernel.org>, <linux-clk@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
 <dri-devel@...ts.freedesktop.org>, <freedreno@...ts.freedesktop.org>,
 "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>, "Abel Vesa"
 <abel.vesa@...aro.org>, "Bjorn Andersson" <andersson@...nel.org>, "Konrad
 Dybcio" <konradybcio@...nel.org>, "Neil Armstrong"
 <neil.armstrong@...aro.org>, "Nishanth Menon" <nm@...com>
Subject: Re: [PATCH 0/2] driver core: platform: / drm/msm: dp: Delay
 applying clock defaults

Hi,

On Thu Aug 14, 2025 at 11:18 AM CEST, Stephan Gerhold wrote:
> Michael had a somewhat related problem in the PVR driver recently [1],
> where of_clk_set_defaults() needs to be called a second time from the PVR
> driver (after the GPU has been powered on) to make the assigned-clock-rates
> work correctly.

I've come back to this and just noticed that the
assigned-clock-rates do actually work. What doesn't work is the
caching of the clock rate. That bug was then masked by calling
of_clk_set_defaults() again in the driver.

Here is what the driver is doing:
 (1) driver gets handle to the clock with clk_get().
 (2) driver enables clock with clk_enable()
 (3) driver does a clk_get_rate() which returns 0, although there is
     already a hardware default in my case. That got me curious
     again..

Now on the k3 platforms the clocking is handled by a firmware and it
appears that the firmware is reporting a clock rate of 0 unless the
clock is actually enabled. After the clock is enabled it will report
the correct rate. (FWIW, I can modify the hardware/firmware default
rate with the assigned-clock-rates DT property).

I've hacked the clock driver to register all clocks with
CLK_GET_RATE_NO_CACHE and then everything is working as expected.

I'm no expert for the clocking framework, but it seems that
clk_get() will ask the HW for the clk rate and caches it early on.

-michael

Download attachment "signature.asc" of type "application/pgp-signature" (298 bytes)