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: <2749454.BddDVKsqQX@diego>
Date: Wed, 15 Oct 2025 15:27:12 +0200
From: Heiko StĂĽbner <heiko@...ech.de>
To: Quentin Schulz <quentin.schulz@...rry.de>
Cc: mturquette@...libre.com, sboyd@...nel.org, zhangqing@...k-chips.com,
 sebastian.reichel@...labora.com, linux-clk@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject:
 Re: [PATCH] clk: rockchip: rk3588: Don't change PLL rates when setting
 dclk_vop2_src

Am Mittwoch, 15. Oktober 2025, 14:58:46 Mitteleuropäische Sommerzeit schrieb Quentin Schulz:
> Hi Heiko,
> 
> On 10/8/25 3:31 PM, Heiko Stuebner wrote:
> > dclk_vop2_src currently has CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT
> > flags set, which is vastly different than dclk_vop0_src or dclk_vop1_src,
> > which have none of those.
> > 
> > With these flags in dclk_vop2_src, actually setting the clock then results
> > in a lot of other peripherals breaking, because setting the rate results
> > in the PLL source getting changed:
> > 
> > [   14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000
> > [   15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000
> > [ clk adjusting every gpll user ]
> > 
> > This includes possibly the other vops, i2s, spdif and even the uarts.
> > Among other possible things, this breaks the uart console on a board
> > I use. Sometimes it recovers later on, but there will be a big block
> 
> I can reproduce on the same board as yours and this fixes the issue 
> indeed (note I can only reproduce for now when display the modetest 
> pattern, otherwise after boot the console seems fine to me).

I boot into a Debian rootfs with fbcon on my system, and the serial
console produces garbled output when the vop adjusts the clock

Sometimes it recovers after a bit, but other times it doesn't

> Reviewed-by: Quentin Schulz <quentin.schulz@...rry.de>
> Tested-by: Quentin Schulz <quentin.schulz@...rry.de> # RK3588 Tiger w/ 
> DP carrierboard

Thanks for testing
Heiko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ