linux-kernel - Re: [PATCH] clk-divider: Fix READ

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: <2145155.R4QWixMtmU@diego>
Date:	Sat, 15 Nov 2014 15:31:06 +0100
From:	Heiko Stübner <heiko@...ech.de>
To:	James Hogan <james.hogan@...tec.com>
Cc:	linux-kernel@...r.kernel.org,
	Mike Turquette <mturquette@...aro.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org,
	Thomas Abraham <thomas.ab@...sung.com>,
	Tomasz Figa <t.figa@...sung.com>,
	Max Schwarz <max.schwarz@...ine.de>, stable@...r.kernel.org
Subject: Re: [PATCH] clk-divider: Fix READ_ONLY when divider > 1

Hi James,

Am Freitag, 14. November 2014, 15:32:09 schrieb James Hogan:
> Commit 79c6ab509558 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in
> v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the
> recalc_rate() and round_rate() clock callbacks to be omitted.
> 
> However using this flag has the unfortunate side effect of causing the
> clock recalculation code when a clock rate change is attempted to always
> treat it as a pass-through clock, i.e. with a fixed divide of 1, which
> may not be the case. Child clock rates are then recalculated using the
> wrong parent rate.
> 
> Therefore instead of dropping the recalc_rate() and round_rate()
> callbacks, alter clk_divider_bestdiv() to always report the current
> divider as the best divider so that it is never altered.
> 
> For me the read only clock was the system clock, which divided the PLL
> rate by 2, from which both the UART and the SPI clocks were divided.
> Initial setting of the UART rate set it correctly, but when the SPI
> clock was set, the other child clocks were miscalculated. The UART clock
> was recalculated using the PLL rate as the parent rate, resulting in a
> UART new_rate of double what it should be, and a UART which spewed forth
> garbage when the rate changes were propagated.
> 
> Signed-off-by: James Hogan <james.hogan@...tec.com>
> Cc: Mike Turquette <mturquette@...aro.org>
> Cc: Heiko Stuebner <heiko@...ech.de>
> Cc: Thomas Abraham <thomas.ab@...sung.com>
> Cc: Tomasz Figa <t.figa@...sung.com>
> Cc: Max Schwarz <max.schwarz@...ine.de>
> Cc: <stable@...r.kernel.org> # v3.16+

Yep, your solution is much better I think.
Reviewed-by: Heiko Stuebner <heiko@...ech.de>


Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/