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  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]
Date:	Thu, 20 Mar 2014 11:59:14 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Kevin Hao' <>,
	Scott Wood <>
CC:	"" <>,
	"Chenhui Zhao" <>,
	"" <>,
	"" <>
Subject: RE: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

From: Kevin Hao
> Sent: 20 March 2014 11:48
> To: Scott Wood
> Cc:; Chenhui Zhao;;
> Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
> On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
> > >  The sequence "write, readback, sync" will guarantee this according to the manual.
> >
> > If you're referring to the section you quoted above, the manual does not
> > say that.  It only talks about when accesses "to memory regions affected
> > by the configuration register write" can be safely made.
>   To guarantee that the results of any sequence of writes to configuration
>   registers are in effect, the final configuration register write should be
>   immediately followed by a read of the same register, and that should be
>   followed by a SYNC instruction. Then accesses can safely be made to memory
>   regions affected by the configuration register write.

That sort of sequence is need to force the operations through any
external bus - after the cpu itself has issued the bus cycles.
Mostly required because writes are often 'posted' (ie address and data
latched, and then performed synchronously).

> According to the above description in t4240 RM manual (2.6.1 Accessing CCSR
> Memory from the Local Processor), that the writing to configuration register
> takes effect is a prerequisite for the memory access to the affected regions.
> OK, so the intention of 'twi, isync' following the load is not to order the
> following storage access, but order the following delay loop instructions,
> right

I tried to work out what the 'twi, isync' instructions were for (in in_le32()).
The best I could come up with was to ensure a synchronous bus-fault.
But bus faults are probably only expected during device probing - not
normal operation, and the instructions will have a significant cost.

Additionally in_le32() and out_le32() both start with a 'sync' instruction.
In many cases that isn't needed either - an explicit iosync() can be
used after groups of instructions.


Powered by blists - more mailing lists