linux-kernel - Re: [PATCH 2/2] AT91 slow-clock resume: don't restore the PLL settings when the PLL was off

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: <1270724213l.12911l.1l@i-dmzi_al.realan.de>
Date:	Thu, 08 Apr 2010 12:56:53 +0200
From:	Anders Larsen <al@...rsen.net>
To:	Andrew Victor <avictor.za@...il.com>
Cc:	Julien Langer <julien.langer@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] AT91 slow-clock resume: don't restore the PLL
 settings when the PLL was off

Hi Andrew,

On 2010-04-06 23:45:41, Andrew Victor wrote:
> I don't think it's sufficient skip the "wait for lock" if the
> PLLA/PLLB value is 0.
> For example, since bit 29 of PLLA is always 1, the wait_pllalock will
> always run - even if MULA is 0 (which means the PLLA is disabled) and
> will therefore never lock.
> Similarly, for other bits in the register which might happen to be set.
> 
> The code should rather be something like:
>   Save PLLA
>   Save PLLB
>   ... wait for interrupt ....
>   Restore PLLB
>   if (PLLB & AT91_PMC_MUL != 0)
>       Wait for PLLB to lock
>   Restore PLLA
>   if (PLLA & AT91_PMC_MUL != 0)
>       Wait for PLLA to lock

point taken.

The (more simple) patch below should match your suggestion
(added as #6043/1 to rmk's tracker):

at91: slow-clock resume: Don't wait for a disabled PLL to lock.

We run into this problem with the PLLB on the at91: ohci-at91 disables the PLLB
when going to suspend. The slowclock code however tries to do the same: It
saves the PLLB register value and when restoring the value during resume, it
waits for the PLLB to lock again. However the PLL will never lock and the loop
would run into its timeout because the slowclock code just stored and restored
an empty register.
This fixes the problem by only restoring PLLA/PLLB when they were enabled
at suspend time.

Signed-off-by: Anders Larsen <al@...rsen.net>
Cc: Andrew Victor <avictor.za@...il.com>
Cc: Julien Langer <julien.langer@...il.com>
---

 arch/arm/mach-at91/pm_slowclock.S |   12 ++++++++++++
 1 file changed, 12 insertions(+)


Index: b/arch/arm/mach-at91/pm_slowclock.S
===================================================================
--- a/arch/arm/mach-at91/pm_slowclock.S
+++ b/arch/arm/mach-at91/pm_slowclock.S
@@ -201,13 +201,25 @@ ENTRY(at91_slow_clock)
 	ldr	r3, .saved_pllbr
 	str	r3, [r1, #(AT91_CKGR_PLLBR - AT91_PMC)]
 
+	tst	r3, #(AT91_PMC_MUL &  0xff0000)
+	bne	1f
+	tst	r3, #(AT91_PMC_MUL & ~0xff0000)
+	beq	2f
+1:
 	wait_pllblock
+2:
 
 	/* Restore PLLA setting */
 	ldr	r3, .saved_pllar
 	str	r3, [r1, #(AT91_CKGR_PLLAR - AT91_PMC)]
 
+	tst	r3, #(AT91_PMC_MUL &  0xff0000)
+	bne	3f
+	tst	r3, #(AT91_PMC_MUL & ~0xff0000)
+	beq	4f
+3:
 	wait_pllalock
+4:
 
 #ifdef SLOWDOWN_MASTER_CLOCK
 	/*

--
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/