linux-kernel - Re: [PATCH 4/4] clk: imx: fracn-gppll: fix pll power up

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] [day] [month] [year] [list]

Message-ID: <4c7956afc86ea05f07b25d98ffb5b80c.sboyd@kernel.org>
Date: Wed, 16 Oct 2024 14:49:55 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Abel Vesa <abelvesa@...nel.org>, Aisheng Dong <aisheng.dong@....com>, Fabio Estevam <festevam@...il.com>, Michael Turquette <mturquette@...libre.com>, Peng Fan (OSS) <peng.fan@....nxp.com>, Pengutronix Kernel Team <kernel@...gutronix.de>, Sascha Hauer <s.hauer@...gutronix.de>, Shawn Guo <shawnguo@...nel.org>
Cc: linux-clk@...r.kernel.org, imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, Peng Fan <peng.fan@....com>, Jacky Bai <ping.bai@....com>
Subject: Re: [PATCH 4/4] clk: imx: fracn-gppll: fix pll power up

Quoting Peng Fan (OSS) (2024-10-14 02:11:25)
> From: Peng Fan <peng.fan@....com>
> 
> To i.MX93 which features dual Cortex-A55 cores and DSU, when using
> writel_relaxed to write value to PLL registers, the value might be
> buffered. To make sure the value has been written into the hardware,
> using readl to read back the register could make sure the value
> written into hardware.
> 
> current PLL power up flow can be simplified as below:
>   1. writel_relaxed to set the PLL POWERUP bit;
>   2. readl_poll_timeout to check the PLL lock bit:
>      a). timeout = ktime_add_us(ktime_get(), timeout_us);
>      b). readl the pll the lock reg;
>      c). check if the pll lock bit ready
>      d). check if timeout
> 
> But in some corner cases, both the write in step 1 and read in
> step 2 will be blocked by other bus transaction in the SoC for a
> long time, saying the value into real hardware is just before step b).
> That means the timeout counting has begins for quite sometime since
> step a), but value still not written into real hardware until bus
> released just at a point before step b).
> 
> Then there maybe chances that the pll lock bit is not ready
> when readl done but the timeout happens. readl_poll_timeout will
> err return due to timeout. To avoid such unexpected failure,
> read back the reg to make sure the write has been done in HW
> reg.
> 
> Introduce fence_write for this purpose.

Please just write out the readl() instead of introducing a bespoke macro
that isn't generic for all architectures.