linux-kernel - RE: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

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: <063D6719AE5E284EB5DD2968C1650D6D0F6E40C4@AcuExch.aculab.com>
Date:	Fri, 21 Mar 2014 09:21:56 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Scott Wood' <scottwood@...escale.com>
CC:	'Kevin Hao' <haokexin@...il.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	Chenhui Zhao <chenhui.zhao@...escale.com>,
	"Jason.Jin@...escale.com" <Jason.Jin@...escale.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

From: Scott Wood [mailto:scottwood@...escale.com]
> On Thu, 2014-03-20 at 11:59 +0000, David Laight wrote:
> > 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.
> 
> The idea is that it's better to be maximally safe by default, and let
> performance critical sections be optimized using raw accessors and
> explicit synchronization if needed, than to have hard-to-debug bugs due
> to missing/wrong sync.  A lot of I/O is slow enough that the performance
> impact doesn't really matter, but the brain-time cost of getting the
> sync right is still there.

Hmmm....

That might be an excuse for the 'sync', but not the twi and isync.

I was setting up a dma request (for the ppc 83xx PCIe bridge) and
was doing back to back little-endian writes into memory.
I had difficulty finding and including header files containing
the definitions for byteswapped accesses I needed.
arch/powerpc/include/asm/swab.h contains some - but I couldn't
work out how to get it included (apart from giving the full path).

In any case you need to understand when synchronisation is
required - otherwise you will get it wrong.
Especially since non-byteswapped accesses are done by direct
access.

	David